@@ -61,6 +61,30 @@ The DM is divided into two submodules the **Dispatcher** and the **Dispatch Daem
...
@@ -61,6 +61,30 @@ The DM is divided into two submodules the **Dispatcher** and the **Dispatch Daem
- For Worker nodes modify the config.json in dispatch_daemon to provide an unique ID to each node.
- For Worker nodes modify the config.json in dispatch_daemon to provide an unique ID to each node.
- Run the Master and Worker server as `npm start` or `node index.js`
- Run the Master and Worker server as `npm start` or `node index.js`
### Internal Communication Interfaces
Internally DM uses Apache Kafka for interaction between the Dispatcher and the Dispatch Agents, while the messages are in JSON format.
Every Dispatch Agent listens on a topic which is its own UID (Currently the primary IP Address), the Dispatcher listens on the topics *"response"* and *"heartbeat"*.
-**Request Message:** When a request is received at the Dispatcher, it directs the Dispatch Agent to start a worker environment. A message is sent via the chose Worker's ID topic. \
Format:
```javascript
{type:"execute",
function_id:"onetime unique ID",
runtime:"isolation runtime",
functionHash:"hash of the function to be run"}
```
-**Response Message:** In response, the worker executes the function, pulling resources from the central repository as required and sends a response. \
Format:
```javascript
{status:'success',
result:'result of the execution',
function_id:'onetime unique ID'}
```
-**Heartbeat Message:** The Dispatch Daemons also publish a periodic Heartbeat message back to the Dispatcher as a liveness test.\
Format:
```javascript
{address:'UID of the worker'}
```
### Interaction API
### Interaction API
The platform works via a HTTP API based interface, the interface is divided into two parts:
The platform works via a HTTP API based interface, the interface is divided into two parts: