Define discovery protocol

[rsiewert]

Define configuration info that any device needs to establish communication within its known network.

[rsiewert]

It needs to have a config for a messaging server( in this case rabbit) so it can publish an awake broadcast message to the network (to which it belongs which is defined by the message broker) . So it needs messaging server IP/Port and exchange/queue/routingKey info.

[rsiewert]

It seems like we might want to have a categorization of rabbit exchanges, not sure how this impacts performance, etc. From a design view though clients can know that sitting on certain exchanges result in certain actions.

[rsiewert]

Something I just drew up to start the discussion/impl { protocol: { 'acts-as':'[server | device]' //required 'rest': { 'domain':'somedomain.com' 'port':'20003', 'endpoint':'/theapp/endpoint', }, 'messenger': { 'exchange':'theExchange, 'queue':'theQueue', 'routingKey','theRoutingKey' //where applicable } } }

[rsiewert]

I've updated the JSON discovery structure to this:

{ "data": { "protocol": { "acts-as": "server", "rest": { "domain": "somedomain.com", "port": "20003", "endpoint": "/theapp/endpoint" }, "messenger": { "exchange": "theExchange", "queue": "theQueue", "routingKey": "theRoutingKey" } } } }

This is well-formed JSON by using JSONLint : http://jsonlint.com/ ... so all that needs to be done, I think is fill in the values for your wakeup publish msg and my nodejs server will persist that to the devices db. My (exchange,queue,routingKey) = (test-exchange,register-queue,the.routing.register)

[rsiewert]

actually you should only need the exchange/routingKey and you should be able to publish ok

[rsiewert]

We cannot have a dash in any key as even though it passes JSONLint it is not accepted by nodejs apparently:

so the JSON reg structure should at least have this key syntax:

{ "data": { "node_id": "some id", "timestamp":"", "protocol": { "acts_as": "server", "rest": { "domain": "somedomain.com", "port": "20003", "endpoint": "/theapp/endpoint" }, "messenger": { "exchange": "theExchange", "queue": "theQueue", "routing_key": "theRoutingKey" } } } }

[rbgodwin]

What is the format of the response message? We need to have I think a sequence number in the response that corresponds to a sequence number in the registration request I think, and a status telling if all went ok or if there was some error. We should enumerate the type of errors. Examples might be DEVICE_ID_TAKEN, SERVER_DOWN, etc. Question - how do we enumerate possible types and share them between our server and remote devices? Maybe we need a /common directory with some headers?

[rsiewert]

Could you add what you think it needs to have and then we can discuss/implement?

Those are all excellent questions that need to be addressed.

[rsiewert]

Seems to me that a device node ( [server | device] ) upon coming up should publish to a known global registration channel and anybody that wants to subscribe to that 'public' channel can do so automatically by just subscribing. Then the other channels could require some sort of level-based auth/author scheme.

[rbgodwin]

I made some mods for the first cut. Here is an example of the JSON for a registration from a device:

{ "message": { "protocol": { "actsAs": "DEVICE", "rest": { "Mirror": { "domain": "192.168.1.44", "port": 3000, "endpoint": "/json-mirror" } }, "messenger": { "on_publish": { "exchange": "deviceExchange.0xfa32da59", "queue": "serviceQueue", "routing_key": "0xfa32da59.routing.on_publish" }, "on_ack": { "exchange": "deviceExchange.0xfa32da59", "queue": "serviceQueue", "routing_key": "0xfa32da59.routing.acks" }, "command_server": { "exchange": "deviceExchange.0xfa32da59", "queue": "serviceQueue", "routing_key": "0xfa32da59.routing.commands" } } }, "originTimestamp": "Mar 5, 2014 6:42:09 PM", "nodeId": "0xfa32da59.gateway", "seqId": 0 } }

[rsiewert]

Do you think that a DEVICE should have a different schema than a SERVER? ... not arguing any position just wondering?....I like ur originTimestamp...what did you use to make it human readable?
...how would seqId be used?

[rsiewert]

We seem to be able to successfully do this locally for the most part, but we need to be remote...I haven't been able to access my rabbitmq remotely yet...not sure why

[rbgodwin]

Verified that all works remotely with a clean ACK. I used a java Date() object and it is turned into JSON via gson for the timestamp. We might change the name of the server side timestamp to "receivedTime"

[rsiewert]

Ok...add any necessary fields that we talked about if any and close this item once the json file has been checked in.

[rsiewert]

just wanted to put this up to reflect the current reg json message structure

{ _id: "479ba5b22f894e584a1648b32b1d6a44", _rev: "1-e781624cc2551295a19103b90e0d931d", data: { message: { protocol: { actsAs: "DEVICE", rest: { Mirror: { domain: "192.168.1.44", port: 3000, endpoint: "/json-mirror" } }, messenger: { on_publish: { exchange: "deviceExchange.0xfa32da59", routing_key: "0xfa32da59.routing.on_publish", manageExchange: false }, on_ack: { exchange: "deviceExchange.0xfa32da59", routing_key: "0xfa32da59.routing.acks", manageExchange: true }, command_server: { exchange: "deviceExchange.0xfa32da59", routing_key: "0xfa32da59.routing.commands", manageExchange: false } } }, originTimestamp: "Mar 7, 2014 8:28:16 PM", nodeId: "0xfa32da59.gateway", seqId: 3, requestAck: true, timestamp: "1394209737275" } } }

[rbgodwin]

Below is an example of the JSON used to register a device. The registration provides information about the device along with communication methods (protocols) to interact with the device. This closes out this issue for sprint2

"message": { "node": { "actsAs": "DEVICE", "nodeId": "0x555903ff.gateway", "location": { "latitude": 40.12, "longitude": 200.34, "altitude": 300.45 }, "status": "YELLOW", "protocol": { "rest": { "Mirror": { "domain": "192.168.1.44", "port": 3000, "endpoint": "/json-mirror" } }, "messenger": { "on_publish": { "exchange": "deviceExchange.0x555903ff", "routing_key": "routing.on_publish", "manageExchange": true }, "heartbeat": { "exchange": "deviceExchange.0x555903ff", "routing_key": "routing.heartbeat", "manageExchange": true }, "on_ack": { "exchange": "deviceExchange.0x555903ff", "routing_key": "routing.acks", "manageExchange": true }, "command_server": { "exchange": "deviceExchange.0x555903ff", "routing_key": "routing.commands", "manageExchange": false } } }, "description": "Test Device" }, "originTimestamp": "Mar 20, 2014 8:46:20 AM", "seqId": 23001, "requestAck": true, "timestamp": 1395290780404 }