Websocket module: notifications through websocket

[fgalan]

(Parent issue: #1181)

We could consider a new kind of subscriptions that instead of sending notifications through HTTP REST use the websocket used to create the subscription in order to send notifications back. A new URL schema (e.g. ws://) could be used so Orion can clearly identify them.

Probably this kind of subscriptions doesn’t need to be persisted in DB (it would live only in CB memory) given that once the websocket is closed by the client, then the subscription is immediately removed.

[ See issue #1943 for details about notifications in Active-Active environment ]

[fgalan]

After today discussions on skype, more info on how implement this.

Let's consider that ws module keeps a table relating subIds (as string) and ws_hdls (websocket handles, in a structure used by the module, @fortizc I understand that you control that part). Table implementation details are out of scope of this description (although probably a std::map could be used). Let's name this table subsWs for convenience in this description (please, use a better name at implementation stage if you find so).

At CB startup time, the table starts empty. Let's consider the different flows:

• Subscription done through websocket. The ws module analyzes if the subscription is of ws nature looking to the reference for the ws:// string. In that case, it processes the message as usual but looks at the subscription response before sending it back to the client to get the subId associated to the subscription. A new entry is added to subsWs linking the subscriptionId to the ws handler (which is kept open).
• Update context triggering the subscription. The CB processes this update as usual (no matter if it arrived on the REST API or in the WS API). In some point of mongoBackend, the notification is triggered and Notifier::sendNotifyContextRequest() is invoked. This function will be modified to look at the reference string:
  • If reference starts with http:// or https:// then perform regular process.
  • If reference starts with ws:// then a callback to ws module is done, including the subId and the notification content. Let's name this function sendNotifyContextRequestWs() for the moment (please, use a better name at implementation stage if you find so). This function looks for subId in the subsWs table to get the corresponding ws_hdls. The ws module sends the notification using ws_hdl. More detail on sendNotifyContextRequestWs() signature in a separate comment.
• If the client closes the ws_hdl, the the ws module does a reverse lookup in the table to get the associated subId (if any) and in that case does an unsubscribe for subId on the lower layer and removes the entry from the table.

[fgalan]

Draft for sendNotifyContextRequestWs() signature:

int sendNotifyContextRequestWs(const std::string& subId,
                                                        const std::map<std::string, std::string>& headers, 
                                                        const std::string& data);

The JSON send back to the client to the ws handler associated to the subscription would be as follows:

{
   "subscriptionId": <subId>,
   "headers": <a keymap rendered from the headers map>,
   "data": <data string, it is assumed that the caller in Notifier module would prepare this to be a valid JSON>
}

The return value is bool to mean sucess or failure but we can set it to void if we find that at the end is not needed or to int if we want to have more granularity about the cause of the problems. We are to use int at the end.

[fgalan]

Suggested work split:

• @fortizc: all the needed modifications in the ws module, including sendNotifyContextRequestWs() implementation.
• @fgalan: client part of the sendNotifyContextRequestWs() in the Notifier module.

[fgalan]

Important remarks: in the above descriptions, "ws://" refers to an exact text (of 5 chars), not to a prefix as it could be "http://".

[fgalan]

Implemented in PR #2004