SchedMSG - Description

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.

Content of Messages

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.

  • broadcast - The payload object will be interpreted as a broadcast message for the worker to display as a pop-up.

• 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.

Sample Message

{
  "type": "broadcast",
  "message": "hello, world",
  "persistent": "true",
  "signature": "ABCBBBDBDBCBCBB#7437274273428BCBCBCB?????",
  "timestamp": "936201600444"
}

Usage

//Usage:
schedmsg.js --type '' --body '' --persistent //don't include persistent for false
//Example:
schedmsg.js --type broadcast --body 'Hello World' --persistent

Messages between worker and scheduler

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 worker timestamp is zero, the message is valid if it is persistent
• If the worker timestamp is greater than zero, the message is valid if it’s timestamp is greater than the worker’s timestamp

Broadcast message

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.

Command message

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.

Types of Commands

• openPopup is used to display a new tab on the client’s window with a given URL
  • Example: --payload 'openPopu,url'
• reload will refresh the portal window, requires the user to sign back in and restart the worker
• restart kills all active worker tasks and restarts the worker. This avoids reloading the page and requiring a log-in
• remove is used to remove all working tasks with a given generator address
  • Usage: --payload 'remove, genId'

Delete Message

The command schedmsg.js --type delete will simply remove any active modal on the user’s screen. The payload and persistent flag are irrelevant.