This question basically makes it sound like the node library Socket.io uses the library engine.io which uses ws.
What role do each of these play given that each one can independantly create a WebSocket connection?
Look at Introducing Socket.IO 1.0 - New engine to see why they made Engine.IO.
Engine.IO has all the browser hacks and different things for compatibility, and has modularised the Socket.IO codebase.
You are correct that Socket.IO uses Enginge.IO which uses ws.
Engine.IO takes care of the connection and browser hacks.
ws is used when upgrading to websockets.
Socket.IO handles:
setup/connection to http.Server. (but engine.io has this as well)
list of clients
rooms
namespaces
decoding/encoding of Socket.IO packet format
Related
I would like to use socket.io or engine.io on client, but does it implies having a corresponding implementation on the server ? so socket.io on Client and a Java server with socket.io for instance ? Thx
Yes, a socket.io client must be talking to a socket.io server on the other end. socket.io is its own protocol on top of webSockets so you must have a reciprocal server on the other end that speaks the same protocol.
There are implementations of socket.io server for many server-side languages, including Java, Javascript, C++, C#, etc...
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 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/
sorry for my dumb question, now that i got that i must use Javascript to use Websocket, this is client-side, but what about Serverside, why do i find people talking about RabbitMQ, Stomp, SocketIO, Tornadio
in the Tornado example, no one of them exists, so i said that Tornado is enough, but i found that people use them even with Tornado, here and here.
So what do i use? and for what?
Actually Tornado is a web-server and it supports web-sockets. Other things in your post are not webservers.
RabbitMQ is a message queue service, it's used to communicate between different services on the server
STOMP is a protocol to work with message queues.
Socket.IO is a framework that allows you to use websockets easily. But it requires Node.JS server on the server side. Socket.IO provides you some fallbacks if browser do not support WS protocol. Tornadio is a port of Socket.IO to Tornado. So you can use the same client framework (in web-browser) but on server-side you use Tornado instead of NodeJS.
So Tornado is enough for websockets. But if you'd like to create more complex apps you'll have to use other tools for other tasks. From your list - you can use Tornadio to deal with legacy browsers and RabbitMQ for interprocess communication on your server
As Websockets are not allways implemented nowadays, some libraries try to circumvent this with the Flash plugin for example. However, that is not always available, and there are Websocket-like features with Ajax connections in frameworks too. However, is there an Websocket standard conforming abstraction library that provides a reliable Websocket in any cases? Eg. cross-browser, firewall safe etc.?
Socket.IO is probably the closest thing. There is a primary server implementation in Node.js but Socket.IO can also be thought of as a higher level protocol layer that can use various transports underneath (with WebSockets being preferred) and as such there are other implementations of Socket.IO servers in other languages.