Websockets. Loss of internet, keep-alive messages, app architecture etc

Question

Well, there's a lof of information about websockets. The technology itself is amazing, there's no doubt in this fact. And before i will start using them in my app i just want the community to answer these questions:

"...in order to maintain presence, the app can send keep-alive messages on the WebSocket to prevent it from being closed due to an idle timeout..."

"...ideally a future version of WebSocket will support timeout discovery, so it can either tell the application the period for keep-alive messages..."

1. This feels like deja vu. Earlier we had to poll the server once a %period_time% to get the needed updated information. With websockets we have to poll the websocket server once a %period_time% with keep-alive messages to make sure the internet connection is still alive / the websocket server is still working. What's the profit?

   And another thing regarding these keep-alive messages. Websocket protocol has an advantage of using less traffic than HTTP(S). If we send keep-alive messages, it seems like the traffic advantage dissapears. Or maybe not?

2. How should i handle the loss of internet in my app if i use websockets? I mean the real situation when the internet connection is suddenly lost (i mean no "navigator.offline" event has happened). Should i use some kind of setTimeout-function to look for keep-alive messages or is there a better way to handle this situation?

3. REST gives us a clear understanding of how an app should work and how the requests should look like. What's the best way of doing this in websocket-powered apps? Should i just have (say) JSON-encoded messages with request.action field it it? And how should the app perform PUT-requests? There are URL-resources in REST model to handle this, so should i use combination of these approaches or maybe is there smth simplier?

Answer 1

I think most of your questions can be clarified by understanding the real purpose of WebSockets. WebSockets was not primarily designed to replace any of the the things that are already in place and working well. For example, it was not designed to be a low-overhead version of AJAX. The purpose is to provide a bidirectional, low latency, full duplex, communication channel between the browser and server. It's real purpose is to enable a new domain of web applications or to improve current ones that are abusing HTTP to achieve bidirectional communication.

With that in mind let me comment on your bullet points:

1. The purpose of periodic WebSockets ping/pong messages is two-fold: to keep the channel from being closed by TCP timeout and to more quickly detect when the channel is closed (this is historically a weakness of TCP). The purpose of HTTP/AJAX polling is to get around the fact that HTTP is not bidirectional (i.e. the client polls to give the server the opportunity to send data back). WebSocket ping/pong frames are generally 2 bytes long. HTTP/AJAX polling requires full headers, cookies, etc which can easily total over a kilobyte for each request/response. Even if you send a ping/pong 10 times a second over WebSockets you are still unlikely to even compare to the overhead of HTTP/AJAX polling every 2 seconds. However, note that applications do not have the ability to send ping/pong messages. This is between the browser and server.

2. If you lose the Internet connection, you will receive an onclose event. If your browser is not doing ping/pong messages for you then you may not receive an onclose until you try to send a message after the network connection goes down.

3. I wouldn't replace a working RESTful service with WebSockets. You would be doing a lot of mapping work for probably very little benefit (again, WebSockets is not designed to replace what's already working well). I can envision situations where you might have a combination of both: REST for state transfer, WebSockets for event notification. E.g. the server sends a WebSocket message indicating "something changed" which triggers the client to do a REST request to find out the change.

Update:

Clarification: you could do REST over WebSockets but it's a mismatch in philosophy. REST is an architecture style that is un-opinionated about the underlying transport system. It is a constrained architecture: "client-server", "stateless", "cacheable", "layered system", "code on demand", and "uniform interface". WebSockets is constrained by none of those; it is a generic message transport system. You could constrain WebSockets to be RESTful but don't do that until you understand both REST and WebSockets intimately and can identify when it's right to do so.