Brainstorm session : How to properly use Websockets in the ESN ?

June 16, 2014 gcrosmarie ESN, 0

At Linagora, we want to build a rich an functional ESN, which means it must have cool features like server notifications, instant messaging, video chat…
This bidirectional clien-server communication can be done using different technologies.
Among these technologies we decided to use Websockets which can be a powerful and efficient way to implement these features.

The problem is, we should be careful on how we build our Websocket strategy in order to really leverage the potential of this technology and make our web application as fast and light as possible.

Our start point for our architecture was that each client must have only one open Websocket to the server. This was dictated by perfomrance concerns on both the client and the server side.
The main problematic using a single Websocket is that many different components use the same single way of communication.

The issues to address are :
• when a event happens on the server and one or more client needs to be notified about it, to which Websockets this event should be piped ?
• when a client sends a message through a Websocket, to which component on the server this message should be passed ?

We thought of two way of solving these problems.

Solution 1 : Server only

The main assumption of this solution is that, the client is not concerned by these problems.

In fact, the client knows its single Websocket and can ignore what really happens on the server :
• it always sends messages through its Websocket.
• it always receives messages thourgh this same single Websocket.

So the client just needs a field in the event received to know how to handle it.

Going by this assumption, all the work is done by the server. And the problematic is how to route all these messages between server components and the Websockets.

More precisely the server has to :
• have the possiblity to maintain groups of Websockets which will be cast the same event because they belong to a same high level functional domain.
• being able to forward the message form a client to the component(s) which can use it.

This solution is very simple conceptually but has a drawback : the routing of the message has to be coded entirely by ourself and according to message data itself.

Existing software for this solution :
• socketio : socketio provides a feature named “rooms”. Each room can have Websockets and when a message is published on a room it is published on all the Websockets it contains. Moreover, a Websocket can be part of multiple rooms. So rooms can allow easy multicast from the server to clients.

Solution 2 : Client & Server

In this solution, the routing of messages is done by both the client and the server.
The main idea of this strategy is that the Websocket library provides a mechanism to define on which functional domain a Websocket is used when sending/listening messages.
Therefore, the communication is tagged and is easily routable on the server side and only demands for a small configuration on the client side.

This solution is a bit more complicated to implement and has a drawback : it requires every communication to be tagged which might create problems due to the management of numerous different tags.

Existing software for this solution :
• socketio : socketio provides a feature called “namespaces”. A Websocket instance can publish and listen on a namespace (a developper chosen String). This allows to tag the exchanged messages according to their meaning in the application.
• websocket-multiplex : a library that provides the same namespace mechanism over a SockJS connection.
• websocket-multiplexer : another library providing namespaces over SockJS and over a Websocket connection.

Conclusion

For the software choice, we decided to use socketio which is currently the richer Websocket implementation because it provides solution for both of the above solutions.

And concerning our Websocket strategy, we decided to go for Solution 2 because it makes the server much simplier and does not demand for a heavy development on the client side.
Moreover, we think it is good practice to have our Webscoket messages tagged with their application meaning : it will make our code easier to write and read (i.e. a better code…)

socketio, websocket

Brainstorming session: XMPP integration into real time web application Apache James with Cassandra