If you want something simpler for real-time communication you can use comet-stream. It goes through all firewalls and scales better than most single threaded websocket servers: https://github.com/tinspin/rupy/wiki/Comet-Stream
The WebSocket Handbook
11–20 of 124 posts
Re: The WebSocket Handbook
#12In case the email collection form gets hugged to death, here's a mirror https://web.archive.org/web/20220111162712/https://files.abl... In our experience, many enterprise networks/vpns/firewalls still break websocket connections even when using wss, and it should not be used as the only communication channel even if you target evergreen browsers.
Disclaimer: I work for Ably. I agree in principle, so the libraries that handle websockets and also fallback transports using comet (eg SocketIO) are still widely used for that reason, and the commercial pub/sub service providers generally also support comet fallbacks. However, we now find that it is really very rare that clients are unable to use wss.
Re: The WebSocket Handbook
#13Hi HN! I'm Alex, and I've been researching and writing about WebSockets for a while now. I'm the author of the recently released WebSocket Handbook. AMA about the WebSocket tech, the realtime web, Ably or anything related to Liverpool FC.
What is the right way to handle authentication over web sockets?
If I understand correctly, websockets is a thin layer on TCP that does buffer data so that the application get the whole message instead of chunks. I recommend using wss to secure the websocket so that it can't be hijacked, then you don't need to send a token in each message and can do an application layer handshake once. Basically the first websock message from the client would be an authentication message with a password, token or what not.
Re: The WebSocket Handbook
#14In case the email collection form gets hugged to death, here's a mirror https://web.archive.org/web/20220111162712/https://files.abl... In our experience, many enterprise networks/vpns/firewalls still break websocket connections even when using wss, and it should not be used as the only communication channel even if you target evergreen browsers.
Thank You for mirror!
Re: The WebSocket Handbook
#15Anyone know of any examples of cool cases where websockets have been used? (Maybe other than games.) I feel like in most cases I see them used the latency gained is basically added back with bloat in other parts.
Re: The WebSocket Handbook
#16We use WebSockets in two regards: handling live page updates via Phoenix Live View for users (eg: real time chat messages, viewer count, etc) and as a transport medium for our real time API. The former is very easy to handle because for the most part users are navigating around pages which can terminate the ws connection and creates a new one (though most of the times not). The advantages Live View provides us is not…
>we disconnect the WebSocket consumers whenever a server is restarted for the update Isn't avoiding this the main selling point for BEAM? As in Erlang: the movie. Can't that be done with websockets?
You could totally do this with BEAM, via hot swapping. The WebSocket processes don't really change, it's the implementation of what happens when messages comes in that changes. So you'd setup your hot swap with this in mind. (The connection processes stay connected and the behavior module is swapped out?)
However, hot swapping is not super common in practice. Mainly because it's added complexity that most people can live without.
Re: The WebSocket Handbook
#17Anyone know of any examples of cool cases where websockets have been used? (Maybe other than games.) I feel like in most cases I see them used the latency gained is basically added back with bloat in other parts.
I just launched this site with websockets: https://hackernews.pro Websockets used for updating Story/Comment data, and User presence
Re: The WebSocket Handbook
#18Earlier quoted context omitted.
>we disconnect the WebSocket consumers whenever a server is restarted for the update Isn't avoiding this the main selling point for BEAM? As in Erlang: the movie. Can't that be done with websockets?
You could totally do this with BEAM, via hot swapping. The WebSocket processes don't really change, it's the implementation of what happens when messages comes in that changes. So you'd setup your hot swap with this in mind. (The connection processes stay connected and the behavior module is swapped out?) However, hot swapping is not super common in practice. Mainly because it's added complexity that most people can…
Right, this is the comment I was going to make as well. It's certainly possible, but there's tradeoffs (mainly around complexity) to code hot-swapping. We haven't implemented it because restarting servers to upgrade code helps everyone prepare for when servers go down for unexpected reasons, or so I like to think :P!
Re: The WebSocket Handbook
#19Hi HN! I'm Alex, and I've been researching and writing about WebSockets for a while now. I'm the author of the recently released WebSocket Handbook. AMA about the WebSocket tech, the realtime web, Ably or anything related to Liverpool FC.
What is the right way to handle authentication over web sockets?
As with REST APIs, you'd want to be able to authenticate to a websocket-based API using either basic auth, or a bearer token-based auth scheme. Unfortunately, the browser websocket API doesn't allow you to specify arbitrary headers in the websocket request, so it's typical instead to have credentials supplied via a query param (such as "accessToken" for a bearer token) in the wss request.
Re: The WebSocket Handbook
#20Anyone know of any examples of cool cases where websockets have been used? (Maybe other than games.) I feel like in most cases I see them used the latency gained is basically added back with bloat in other parts.
Pretty much every app that has a real-time communication component relies heavily on websockets. Slack and other messaging apps, document editors, financial tickers, sports sites.