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

2

19

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?

Pasteurize answered 6/1, 2012 at 13:39 Comment(2)
This question is not a good fit to our Q&A format. We expect answers to generally involve facts, references, or specific expertise; this question will likely solicit opinion, debate, arguments, polling, or extended discussion.Deranged
@Deranged i thought stackoverflow is the best way to get the answers regarding this technology. I just want to listen to the people who know the answers to these questions. In fact no debate needed.Pasteurize
C
17

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.

Cherokee answered 6/1, 2012 at 16:43 Comment(6)
One question regarding the third point: what does the binary data sending opportunity in websockets stands for? maybe this is the thing which should replace REST?Pasteurize
WebSockets has support for sending either UTF-8 strings or raw binary data. The type of the frame is based on the object used in the send() call. If you send a string then it is sent as a a UTF-8 text frame. If you send a Blob or a Typed Array (ArrayBuffer) then it will be sent as a binary frame. If the server sends a binary frame to the client, the type of object received from onmessage() depends on the setting of the binaryType attribute on the WebSocket object ("blob" or "arraybuffer"). If you need low latency transfer of binary data than WebSockets is good match.Cherokee
Regarding the update 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? The technology can't be useful if people just talk about it. I have used some of REST API services and i have created one on my own. This time i want to change my mind and find a real practical use of the websocket technology by switching from REST to websocket communication. Why is it so bad? Which REST/HTTP features can't be implemented using websockets?Pasteurize
[... Snide remark removed about downvoting an answer that goes above and beyond...]. Most WebSocket apps are still in development (it has only been officially standardized for less than a month). However, my noVNC project has been deployed in numerous production environments for over a year. It streams binary data over WebSockets and requires a low-latency bidirectional channel. So extending network protocols to browser (the RFB/VNC protocol is not RESTful). Messaging Queues are also a great use of WebSockets: jmesnil.net/stomp-websocket/docCherokee
REST via WebSockets is not bad (I didn't say that) and you could do it (which I indicated), it's just a mismatch in philosophy and purpose and would be a lot of work for very little gain (unless you NEED very low-latency, bidirectional REST which is unlikely due to the stateless nature of RESTful applications). WebSockets is stateful, REST is stateless, WebSockets is not cacheable, REST is cacheable, REST has a uniform interface, with WebSockets you would need to define your own "uniform" mapping, etc, etc.Cherokee
Generally WebSockets are used to add realtime interactive and engaging functionality to apps e.g. push notifications, activity streams, chat (I know!), realtime commenting, realtime data integration (yes, stock quotes but also sports, travel, environmental, social media data etc.), synchronisation and game state/player movement to name a few. You can see a bunch of uses of WebSockets "in the wild" here: pusher.com/examples. rawkets.com and isocity.co.uk are also pretty cool HTML5 multiplayer game examples which use WebSockets.Discriminative
D
5

"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.

Dicarlo answered 22/1, 2012 at 21:9 Comment(1)
Here are two: hacks.mozilla.org/2012/03/browserquest, html5games.net/puzzle/word-squaredTailspin

© 2022 - 2024 — McMap. All rights reserved.