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 w

Answer 1

"Please stop saying common words and tell how many real practical cases of using websockets in production-ready apps do you know except chats and stock exchange apps?"

I've used websockets for multiplayer support in a space ship action game. Websockets is a really cool technology, but I also find it frustratingly unpredictable - which is probably just me being a novice and making some mistakes. If I had more of the bugs worked out I might have put a link, but it crashes too much, so I don't have it on a live server at the moment.

I suppose that would qualify it as a NON-production-ready app, but hypothetically I don't see why someone else with more experience wouldn't have already done it well.

Answer 2

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.