Websocket Support for Context Broker

[IAIS4EP]

Websocket Support for Context Broker:

In order to make the device and backend communication efficient it is desired by the Orion Context broker to support Websocket transport protocol.

[fgalan]

Related questions at SOF:

• http://stackoverflow.com/questions/32402035/fiware-orion-websocket-support
• http://stackoverflow.com/questions/29930412/orion-context-broker-context-subscriptions-with-android-client

[jmrobles]

+1 (and congrats, Orion is becoming a really important piece of IoT infrastructure)

[fgalan]

CC: @fortizc

We are going to start this work in November 2015 sprint. Let's see how it goes... :)

[jmrobles]

Olé!! 👍
Just in time! We need that feature in this moment.
Thanks!

[fgalan]

A first proof of concept will be done, based on the following encoding:

{
   "verb": "POST",
   "url": "/v2/entities",
   "headers": {
      "Fiware-Service": "myServ",
      "Fiware-ServicePath": "/test2",
      "X-Auth-Token": <...>
   },
   "payload": {
      "type": "Room",
      "id": "Bcn-Welt",
      "temperature": 21.7,
      "humidity": 60,
      "location": {
         "value": "41.3763726, 2.1864475",
         "type": "geo:point",
         "crs": "WGS84"
      }
    }
}

(Responses will be encoded in a similar way)

That way, it could be relatively easy to "link" the fields in the above JSON envelop with the current CB logic (ConnectionInfo mainly).

I would like to stress that this would be a first proof of concept. Once we achieve this step, evolutions and optimization of it would be done (anybody is welcome to suggest! please use the comments to this issue).

[fortizc]

Add a little example of libwebsockets a server and the client

[jbheren]

+1 This is woulde me a must, actually Orion's subscription needs an external url to receive messages

It would be a must Orion had a subscribe mechanism in the way Faye makes it : a client that has internet access subscribes to a channel on the server & stays connected using a socket.

Wish you the Best

[nkittsteiner]

+1 This could be very interesting in the context of working with actuators, for instance, operating a motorized robot remotely

[fgalan]

A first proof of concept prototype has been developed (soon to be landed in the feature/1181_websockets so interested people may test and provide feedback). In order to complete the implementation so this code may land in develop branch some pending task should be completed:

• Websockets module: include header in input envelope #1666
• Websockets module: avoid size limitations #1667
• Websockets module: include status code and headers in output messages #1668
• Websocket module: notifications through websocket #1669
• Websockets module: align with Context Broker common code style #1665
• Websockets module: documentation #1670
• Websocket module: unhardwire configurable aspects #1671
• Websocket module: covering with test harness #1672

[cdupont]

Hello,
this looks like a very interesting/important feature. Can I ask what is the status? Thanks

[fgalan]

Current status involves two branches:

• feature/1181_websockets: a proof-of-concept to support websocket based subscriptions, developed time ago (around April 2016). It is not a full implementation, four sub-issues are still peding (see above list).
• task/1181_libwebsocket_build_doc: a branch of the former with documentation bits, pending to be merged (see FIX add libwebsocket installation instructions #1823, specially the "What is pending" preamble).

Taking into account the implementation is pretty old and that CB has evolved a lot during last year, probably it doesn't make much sense to complete the sub-issues for feature/1181_websocket to merge it into master. However, it can be very useful to guide a new implementaiton in a fresh branch. That's the point with proof-of-concepts: they allow to test and learn before the definitive implementation :)

Unfortunatelly, websockets are not currently a priority for us so we are not puting effort into this at the present moment.