I am searching for a server push technology for my web application.
I would like to use a similar technology as StackOverflow, as that one is working very well.
So, are there any suggestions?
For server-to-client push Server-Sent Events is a better choice than WebSockets. GitHub uses SSE for automatically showing new comments, pull requests, etc.
SSE is HTTP-compatible, so it will work with proxy servers and you won't need HTTPS to have it working in practice (e.g. plenty of mobile operators have a HTTP proxy that breaks unencrypted WebSockets, but SSE works fine).
SSE connection is lightweight and quick. There's no extra handshake and connection upgrade procedure. If you have SSE on every page, then your server will have less work to do.
SSE protocol is super simple. You don't need special web server or library for it, and it can be polyfilled for old browsers.
I suggest you have a look at QWebSockets, if you control the server-side.
Otherwise, socket.io is a good candidate.
There are also ghosted services like Pusher and PubNub, which are free for a moderate number of push messages.
Related
First of, I read the information here http://signalr.net/
You may have heard of WebSockets, a new HTML5 API that enables bi-directional communication between the browser and server. SignalR will use WebSockets under the covers when it's available, and gracefully fallback to other techniques and technologies when it isn't, while your application code stays the same.
SignalR also provides a very simple, high-level API for doing server to client RPC (call JavaScript functions in your clients' browsers from server-side .NET code) in your ASP.NET application, as well as adding useful hooks for connection management, e.g. connect/disconnect events, grouping connections, authorization.
And from answer here: How SignalR works internally?
SignalR has a few built in transports:
WebSockets
Server Sent Events
Forever Frame
Long polling
I have a little problem with understanding the article (theoretically).
So how does SignalR work briefly for each build in transports? (easy English may help, since I'm complete new to SignalR and web socket)
WebSockets
Server Sent Events
Forever Frame
Long polling
What's the reason for not seeing even a handful of "useful" and publicly available websocket based services out there?
RESTful services are plenty like the one below which is weather forecast related.
http://api.openweathermap.org/data/2.5/forecast?q=chicago,us&mode=json
However, why aren't there services like
ws://api.openweathermap.org/...
with some documentation about what messages a websocket client can expect to send and receive bi-directionally over a single connection?
What's the reason for not seeing even a handful of "useful" and publicly available websocket based services out there?
Maybe because websockets were not created for that? They came from the HTML5 initiative and were created to replace Ajax interaction between a browser and a web site for real time web applications. No more polling, long-polling, streaming, flash sockets, or any other HTTP hack to make a server push data to the browser. Webocket is the real thing.
Most web services now follow a request/reply pattern while the websocket is still a maturing technology. Give it time and services will appear, services that actually need the capabilities of websockets and not use them just because "there is a new kid in town".
As a final note, here is something for websockets emerging from Microsoft.
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.
I would like to see if someone can clarify me some concepts I still don´t get about integration of web applications. Up until now, I´ve been working with CometD and Activemq in a project that´s been there for several years but, for what I´ve seen, there are other options out there much more simpler and supported by the community but I still don´t get the whole picture of options available.
So, for what I understand, at the moment, the most common way of getting server pushed events to a client is using websockets. The implementation is server specific and the most used one seems to be the Jetty one. But, because it requires a websocket compatible browser, there are some frameworks that are able to provide websockets and fall to reverse ajax techniques in case this is not an option, like SockJS, that has an implementation for client and for server side. Based on this, as of spring 4 there are templates that allow you to use SockJS behind the scenes and just provide the client implementation of the code using SockJS and letting the programmer to handle the server side in a more easy way.
Apart from this, brokers can understand the websocket protocol so a broker can receive a message from a web browser and then send a message back directly. There is also the STOMP protocol that brokers also implement that allows the system to send/receive messages through websocket to/from the web browser.
One question I have about this is, is STOMP the protocol always used by the broker to send or receive a message to or from a web browser? Or is just one alternative? What is the difference if it´s the later?
Yet another option I´ve seen is using a framework like camel. In this case, the web browser would talk to the websocket component of camel and from there it could be routed directly to the broker using jms. The benefit I see on this is the possibility of introducing processors as part of the route from the browser to the broker, allowing further security processing and reducing the traffic the broker would have to handle in case of not valid/unauthorized messages. Camel would even be able to listen to messages using the STOMP component what would be yet another routing option.
So, to this point, I don´t know if my understanding is correct or if I miss or misunderstand something. If everything is right, it seems that using a framework like SockJS is the best option available at the moment. The use of Spring 4 to simplify things is an option but not really necessary. If the project requires the integration of different systems using a jms broker, the implementation then falls to use SockJS to send messages to the server side and then just route the messages to the correct system. But at this point, there are the options mentioned before like using camel to route the messages or directly send messages to the broker. What would be the best option, or what would be the differences? If I add STOMP to the problem, what does this protocol give me that I can´t handle just with websockets or camel?
I hope I made myself clear. I think this topic includes several technologies and frameworks and it´s quite difficult to express all my concerns without extending the post to much.
Thanks in advance.
In a nutshell, if you want messaging semantics, you should use a messaging protocol such as STOMP. WebSockets sure can handle communication to browsers just fine, but that's just "any custom communication".
The system design may be cleaner if you design around the convention of topics and messaging. The server backend processes can easily push data to a topic that is propagated to all clients, ideally with no further customization.
Aside from STOMP, there is a similar protocol, MQTT which also can run over websockets. A chat demo is provided by ActiveMQ distribution. MQTT is very hot in the Machine2Machine world "internet of things", but I have used it with success in web-deployments too. MQTT should, at least in theory, run pretty good, with low overhead in phone apps, should you ever consider writing one side by side with your website. Then it can be good to use a single setup to communicate "push" data with your clients. Otherwise, your app may have used MQTT, your browser app would have used plain websocket, your backend would have needed another way to pass async events to clients (via some Camel router or similar) and so forth.
I had a huge confusion in WebSockets. I read some blog about WebSockets and it requires node websocket server, I downloaded the demo files and the chat application didn't seem to work. To summarize this, what do I need to use WebSockets? Do I need to download node server or something? And what is something to relate with socket.io to one another?
WebSockets?
WebSockets is a standard for implementing socket communication (to a server) over the web.
Is node required?
Now this server which the socket communication prevails between can be implemented in any way whatsoever. Node is surely a popular option to implement the server side in however its not the only, you can use python, erlang, ruby, or any other language where you can bind a socket connection.
What is socket.io?
socket.io is javascript library which makes it possible for socket OR socket-like connections over the web. See the WebSockets is a recent standard, not all browsers support it, only the modern ones do (proof: http://caniuse.com/#search=websockets). What makes socket.io so popular, rainbow and fairy tale like (and one of the main reasons why you happened to stumble upon it while researching WebSockets) is that it will make socket/socket-like communications possible in all browsers.
socket: when socket.io detects a browser supporting WebSockets, in which case it uses this WebSockets implementation for the socket communications.
socket-like: however when socket.io detects a browser which does NOT support WebSockets it will still provide you with socket-like communication. Tid bit: the internals of this feature use AJAX polling.
Node is a good place to start for websockets, but by no means the only place.
I would probably start here:
http://www.html5rocks.com/en/tutorials/websockets/basics/