Nowadays the go-to alternative for real-time browser-based chat rooms seems to be WebSockets. But I remember being in browser chat rooms way before WebSockets saw the light of day. Was it all just based on AJAX polling? Before that I'm assuming it was based on refreshing the actual page.
There were/are some alternatives:
Simple HTTP pooling, e.g. every 5 seconds you make a GET request to get new messages from server. Not very good from traffic point of view.
BOSH protocol https://en.wikipedia.org/wiki/BOSH_(protocol). This is some kind of WebSockets emulation on top of HTTP. I know some projects still use it.
HTTP Long-polling
From what I see, BOSH protocol and HTTP Long-polling are still alive and used in some specific use cases.
Related
I am working on a project which is basically a Customer Feedback Analysis Dashboard. There are few graphs on the dashboard and data for each graph is fetched from the server through API requests.
Right now the dashboard is updated every time the page is refreshed. I want it to be updated immediately when there is a new feedback in the system. I am confused, whether I use websockets to send data for each graph or just a flag and use that flag to fetch data through API requests.
Like, facebook/twitter does. They tell you about new posts/tweets and when you click that button your feed/wall gets updated.
If you want to "push" data from server to client and you want that data to show up in a timely fashion (e.g. within 10-20 seconds of when it was available on the server), then you will want to implement some sort of "push" solution where the server can efficiently push data to the client whenever there is new data to send.
There are several possible approaches:
webSockets
socket.io
Server-sent events
Mobile platform-specific push (Android and iOS)
For a general purpose solution that works within a browser, you will want to use one of the first three. socket.io is built on top of webSockets (it just adds more features) so architecturally, they are similar.
Server-sent events are fairly new (modern browsers only) and are only for one way communication (from server to client). webSockets can be used for communication either way.
I'd personally recommend socket.io because of the features it offers (such as automatic client reconnection) and a simplified messaging layer. You can see the feature difference between socket.io and webSockets here. With socket.io, the client makes a connection to the server when the web page is loaded and that connection is persistent. After the connection is established, then either client or server can send messages to the other at any time in a very efficient manner.
Other useful references:
Push notification | is websocket mandatory?
websocket vs rest API for real time data?
Why to use websocket and what is the advantage of using it?
What are the pitfalls of using Websockets in place of RESTful HTTP?
Ajax vs Socket.io
I built a realtime application that, thanks to Socket.IO, can serve a lot of different client types (C#, Java, Browser, ...)! I know that there are a lot of Socket.IO alternatives, but from my understanding, everything is more or less based on WebSockets. (I know that Socket.IO has fallbacks if WebSockets are not working, but that they are more less "inferior workarounds" so to speak...)
My question is: Is there any comparable real-time engine available that is NOT based on WebSockets, but can still serve all those different clients?
You don't say what your endpoints are. If one of the endpoints is a browser with purely the built-in capabilities of the browser and Javascript, then a webSocket is your only way to get a continuous connection from the browser to some other destination.
If a webSocket is not supported (in an older browser), then the other socket.io fallbacks (such as xhr-long-polling) are the next best alternatives. As the browser has limited communication capabilities, if you can't use a webSocket, then an ajax call is your only other generally supported option without requiring plug-ins on each browser (such as Flash or Java or something like that). socket.io already supports the next-best options that are available in a browser - you can't do better than that if you're talking about a standard browser with no custom plug-ins.
If your endpoints don't necessarily include a browser and you can use any language or library you want, then you can use plain TCP sockets and then use whatever protocol you want over a TCP socket.
The WebSocket protocol establishes a bidirectional communication channel between server and client; they kind of speak more naturally with each other. The server can just send something to the client and the other way around. In http it just goes in one direction, there's a request and a response and everything needs to be initiated with a request from the client.
From my experience, realtime webApps like a multiplayer game or a chat become easier to develop and it apparently creates less overhead than using http - but still you can do the same things more or less elegant with http as well (see e.g. long polling).
Look at gmail or other existing webApps, they all use http (so does Socket.io as a fallback) and it works quite well.
First off - I understand SPDY and Websockets aren't the same thing, and that you can run Websockets over SPDY like you can with HTTP, etc.
However - I am wondering if SPDY would be a viable replacement for websockets if I am trying to provide a REST (like) API that also supports server push (bi-directional calls over the same connection).
My current prototype uses websockets (node+socket.io), and works fine. However, my issue with websockets is I am having to dream up my own JSON protocol for routing requests both to and from the server. I'd much rather use REST-style URIs and Headers in requests, which fits better in a REST-based architecture. SPDY seems like it would support this better.
Also, because of the lack of headers, I'm concerned websockets won't fit well in our deployment network, and thinking SPDY would be a better fit again.
However, I've not seen many examples of bidirectional SPDY requests, apart from pushing files to the browser. I would like to push events and data to the browsers, such as:
Content-Type: application/json
{
"id": "ca823f3e233233",
"name": "Greg Brady"
}
but it's not clear to me how the browser/Javascript might "listen" and react to these, as I would with the WebSocket and socket.io APIs.
Let's start from the beginning: why would you want to run WebSockets over SPDY, as opposed to doing an HTTP upgrade? If you upgrade an HTTP connection to WS, then nothing else can use that TCP stream - the WS connection can be idle, but the connection is blocked nonetheless. With SPDY, you can mux multiple requests/responses, and a websocket connection (or even multiple) over the same underlying TCP stream. On a practical note, as of July 2012, WS over SPDY is still a work in progress, so you will have to wait to use SPDY for WebSockets - hopefully not too long though!
But let's assume the support is there... The reason why it's not clear how to listen for "SPDY Push" from JavaScript is because there is no way to do that! A pushed resource goes into your browsers cache - nothing more, nothing less. If you need to stream data to your javascript callbacks, then WebSockets, or Server-Sent Events (SSE) is the answer.
So, putting it all together:
HTTP adds a lot of overhead for individual small requests (headers, etc)
WebSockets gives you a low overhead channel, but requires you implement own routing
SPDY will significantly reduce the overhead and cost of small HTTP requests (win)
SSE is a good, simple alternative to pushing data to the client (which works today, over SPDY)
You could use SPDY+SSE to meet your goals, and all of that communication can run over the same TCP channel. SPDY requests to the server, SSE push from the server.
First some clarifications:
The base WebSocket protocol (IETF 6455) is not layered onto HTTP. The initial handshake for WebSocket connections is HTTP compatible, but once the handshake is completed, the protocol is a framed, bi-directional full-duplex connection with very low overhead (often just 2 bytes per frame of header).
The WebSocket over SPDY idea is a proposal that may or may not see the light of day. In this case, WebSocket is in fact being layered on SPDY. The initial connection/handshake may happen faster due to the nature of SPDY versus HTTP, however, the data frames will have more overhead because the WebSocket header fields are mapped into SPDY header fields.
SPDY aims to be a more efficient replacement for HTTP. WebSocket is an entirely different beast that enables very low-latency bi-directional/full-duplex messaging between the client and server.
If what you are interested in server-push with a simple API and you don't need super low-latency, then you might consider server-sent events which has an API that is simple and similar to the WebSocket API. Or you could look into one of the many good Comet libraries which enable server-push but will better support old browsers unlike any of the above solutions.
However, my issue with websockets is I am having to dream up my own
JSON protocol for routing requests both to and from the server.
I wrote a thin RPC layer over socket.io wrapping network calls in promises just for that reason. You can take a peek at it here.
I'm currently building a realtime application using Node. I'm using socket.io to power my real-time interactions, but have jQuery loaded, so I have AJAX available to me. I initially used socket.io for all my communication between the server and client.
I'm starting to think that AJAX might be better suited for certain cases like doing RESTful transactions asynchronously, because I don't have to write a separate message case in my socket to handle each new transaction as well as write the RESTful routing.
I'm wondering if I am on to something or if its best to use sockets for performance or something else I'm not thinking about.
Thanks!
Matt Mueller
Yes, WebSockets (RFC 6455) and Ajax are quite different and serve different purposes.
As you say, with Ajax you can do RESTful requests. This means that you can take advantage of existing HTTP-infrastructure like e.g. proxies to cache requests and use conditional get requests. Ajax request may be quite heavy-weight since every Ajax request contains HTTP headers and include cookies.
WebSockets is designed for low latency bi-directional communication. By design, WebSockets has very little overhead in each message. E.g. WebSockets messages doesn't have to include any HTTP Headers, and may in future be used for VoIP and streaming in both directions.
Another difference is that Ajax can be used with stateless servers. E.g. if you have your web load balanced with multiple servers, any server can handle an Ajax request, even after reboot (or upgrade). Websocket's are "connected" and use a stateful server, so it may be harder to use multiple servers with it.
There is also Server Sent Events, that are similar to WebSockets, in that the server can push data to the client (which can't be done with Ajax without hacks (e.g. comet)), and it can also handle automatic reconnections. But it's only for messages in one direction (server to client). See HTML5 Server-Side Event: EventSource vs. wrapped WebSocket.
Those are two completely different technologies and could be used together: with AJAX the request is initiated by the client, while with WebSockets the request is initiated by the server in order to push some data to the client.
I've implemented a web chat system using Jabber, with the Tigase server and an Ajax-based client communicating over BOSH using JsJac, with Apache mod_proxy forwarding the HTTP traffic to Tigase. This works reasonably well, but I've noticed one major gap in performance versus a desktop Jabber client (like Exodus), particularly when joining a multi-user chat with a long history of messages.
Specifically, from monitoring HTTP traffic, it appears that the server can only send one XMPP message per HTTP request-response cycle. For normal usage this is fine (we're getting roughly 80-100msec round-trip times, which isn't too bad), but when loading MUC history it can be a real drag.
So my question is: does Jabber or BOSH provide any mechanism for bundling or streaming messages that might apply to this use case? Are any clients and servers out there implementing something like this already? Or would I have to modify Tigase and JsJac myself (which is certainly possible, but not ideal)?
Actually, the BOSH server can collect as many responses from the Jabber server and send them as one single response to the client. I am the author of one such BOSH library: http://code.google.com/p/node-xmpp-bosh/.
The response body has nothing to do with the request body in case of BOSH. I mean that the response could and mostly will be a response to an unrelated request (mostly a later request).
I have implemented a BOSH communications solution with Java on the server and GWT on the client (a browser). A C client implementation has also been made. Presently, I am in the process of making the solution available online for tests. Please take a look at the following Google presentation to see if my solution is relevant for your business:
https://docs.google.com/present/edit?id=0AUPL-u98h45WZGQzNWNjOGhfMGd6bWI1NmNk&hl=en&authkey=CPTzrWc
To see the speaker notes, make sure you hit the "View Speaker Notes" button in the bottom-right corner of the page.