Message Specification

As of now the only message format supported is in JSON format. Currently there is no need of another format because all clients are required to have a JSON parser. Providing a JSON message format allows clients to be written in any language that can parse JSON. The first 16 bytes of the message are reserved for the message type. The rest of the message is the JSON message. The reason for this is that knowing what to expect from a json string before its parsed can be useful in parsing it.

Required Fields

These are the fields that must be present in each message. If they are missing then they are considered incomplete. The client will reject incomplete messages and return a message with the message format error. If the response of a message is meant to go to another queue, then the routing_key is set accordingly.

The message is not a valid JSON string until the message type is separated from the rest of the message. The type is always 16 bytes. If the message type is less than 16 bytes then padding is used.

Example Message: "run_job#########{...} In the payload above, the run_job will be the type of the message, the ######### is the padding. The rest is the json to be parsed.

Types

• greet - initiate registration between clients

  • When a node starts up and connects to the server it will send a broadcast message to all other connected clients with information about itself. Then the clients will reply with a greet message to the new node. When a node receives a greet message they will register or update their own registries with the new node. It is up to the client to receive or respond to these messages, therefore the clients choose to register other nodes or not.
  • Required Fields:
    • hostname - sender's hostname
    • ip_address - sender's ip address
    • exchange - sender's queue exchange
    • queue - sender's queue name
    • os - sender's operating system
    • os_version - sender's respective os version
    • purpose - description of the sender's actions

• request_info - get info on the recepient's actions

  • When information is needed about the capabilities of the recepient then this message is sent. This message works in par with the send_info type, which is sent only when this one is received. As of now the message is just logged, however in the future a schema will be define to give meaning to information and it will help the system become autonomous.
  • Requred Fields:
  • sub_type - the message type for the subsection of information

• send_info - set information to the requester

  • When requested to send information this type is required to reply. The information is presented in a single field so that its format can easily change. The information schema depends on the sub type specified by the request_info field.
  • Required Fields:
  • requested_type - this is the same as the sub_type requested
    • info - this is the blob of information
    • format - this is the format of the information

• run_job - request to run a job on the recepient's machine

  • This type is soley used for start jobs on the recepient's machine. An acknowledgement is required to prevent re-running jobs. The job has to be something that is supported by the client. If a job fails or does not exist then an error is returned. The sender may choose to receive the return value of the job or not. If the return value is requested then the sender stores a job ID. When a message containing a stored job ID is received then the return value is recognized to be from the job run request. This allows the sender to continue without being held by the pending return value
  • Required Fields:
  • name - the name of the job (may not be function name)
    • args - the arguments of the job as list (defaults to empty list)
    • send_return_value - a boolean whether to get the return value
    • id - the ID is for the sender to keep track of pending return values

• job_return_value - the return value of a finished job

  • This is only sent if the run_job message requested a return value. The format of the return value depends on the job that was run. Therefore the values need to be JSON serializable. This message must also send the job ID specified by the run_job message. This message can also just represent the completion of a job, when the return value is ignored.
  • Required Fields:
  • status - the status of the job (either success or failed)
  • return_value - the job's return value
    • id - the ID specified by the requester