The schedmsg program provides an interface to interact with the workers, or leaf nodes in DCP. It is able to send message objects to the scheduler, which will then be interpreted and relayed to the worker. The worker can execute tasks if needed and return objects to the scheduler.
The messages to the schedule are JSON signed with the DCP protocol library which encode JSON having the following properties:
type - A string which indicates the type of message, and how the Worker should interpret the payload field.
payload - A string object that includes the instruction for the worker.
signature - The scheduler will access the database of allowed keys to make sure that the signature is valid.
persistent flag - Persistent messages will be sent to new workers. By default, this flag is set to false.
timestamp - Will contain the time (in milliseconds since the epoch) when the message was received by the scheduler. Note: To avoid inconsistency between possibly de-synced clocks, the timestamp will be added by the scheduler and not the client.
{
"type": "broadcast",
"message": "hello, world",
"persistent": "true",
"signature": "ABCBBBDBDBCBCBB#7437274273428BCBCBCB?????",
"timestamp": "936201600444"
}
//Usage:
schedmsg.js --type '' --body '' --persistent //don't include persistent for false
//Example:
schedmsg.js --type broadcast --body 'Hello World' --persistent
Workers routinely communicate with the scheduler to fetch tasks, return result, and perform other tasks. When this happens, the worker will return the timestamp of the last task it worked on. If it is a new worker, the timestamp will be zero. During this time, the timestamp of the worker and the message from schedmsg will be compared to determine if the message should be sent to the worker. There are two cases where the message is considered to be valid:
If the message type is broadcast and is considered valid, a modal will be displayed on the user’s screen that contains the payload object of the message as the dialogue. The user can hit Cancel, Continue, or X to close the modal. If a modal is being displayed when a new broadcast message is sent, the new message will replace the old one. To avoid duplicate messages, a browser tab will only display a given message once, unless refreshed.
If the message type if command, the payload property will be treated as a command to be executed by the portal. The user can specify what type of command they want to execute, and provide an extra parameter if necessary. All command messages will be set to persistent : false
regardless of the flag set by the user.
openPopup
is used to display a new tab on the client’s window with a given URL
--payload 'openPopu,url'
reload
will refresh the portal window, requires the user to sign back in and restart the workerrestart
kills all active worker tasks and restarts the worker. This avoids reloading the page and requiring a log-inremove
is used to remove all working tasks with a given generator address
--payload 'remove, genId'
The command schedmsg.js --type delete
will simply remove any active modal on the user’s screen. The payload and persistent flag are irrelevant.