MV Message Format

Table of Contents Overview Message Tags FUNC_CALL FUNC_CALL_RET EVENT_OCURR REPLY PROP_ADD PROP_SET PROP_GET EVENT_ADD Q: Why not just FUNC_CALL?

Overview

• An MV message which is transferred between devices is a string (char *), which is in JSON format.
  • See http://en.wikipedia.org/wiki/JSON for details on JSON. JSON allows to specify values of following complex types (in addition to primitive types such as numbers and strings)
    • array (ordered list of values):

      [ 1 2 3 ]

    • object (unordered list of key-value pairs):

      { "key1" : "value1", "key2", "value2" }

• An MV message is an JSON object, which contains at least two keys: tag, src, and arg
  • "tag" represents the type of the message sent
  • "src" represents the name of the device which sent this message
  • "arg" represents the payload associated the given message tag; the fields of the "arg" may differ depending on the message tag.

{
  "tag" : "FUNC_CALL",
  "src" : "source-device",
  "arg" : {
             "name" : "foo",
             "funarg" : [ 1 2 ]
          }
}

Message Tags

FUNC_CALL

• FUNC_CALL message represents a remote procedure call request.
• "arg" contains at least two keys: "name" and "funarg".
  • "name" is the name of the function provided by the device which the message is sent to.
  • "funarg" is the argument for this function call request -- since value of "funarg" key van be an arbitrarily-complex JSON value

{
  "tag" : "FUNC_CALL",
  "src" : "source-device",
  "arg" : {
             "name" : "foo",
             "funarg" : [ 1 2 ]
          }
}

• • "funarg"

FUNC_CALL_RET

• "arg" contains at least three keys: "name", "funarg", "retid"
  • "name" is the name of the function provided by the device which the message is sent to.
  • "funarg" is the argument for this function call request -- since value of "funarg" key van be an arbitrarily-complex JSON value
  • "retid" is a token used by the caller to associate the return value to its original caller. Note that unlike sequential programs, there can be multiple function calls alive at the time time -- some calls may be invoking the same function

{
  "tag" : "FUNC_CALL",
  "src" : "source-device",
  "arg" : {
             "name" : "foo",
             "funarg" : [ 1 2 ],
             "retid" : 31482
          }
}

EVENT_OCURR

REPLY

{
  "tag" : "REPLY",
  "src" : "source-device",
  "arg" : {
             "retval" : [ 1 2 ],
             "retid" : 31482
          }
}

PROP_ADD

PROP_SET

PROP_GET

EVENT_ADD

Q: Why not just FUNC_CALL?

• Actually, one message tag FUNC_CALL may be enough.
  • However, let's we have only support one tag FUNC_CALL. Then we would require second-leve tag which specifies "which function" to call. After all, we would need all above tags.