I have seen two implementation of websocket in dart:io and dart:html. Which one should I use? Currently I prefer more the websocket in dart:io since it seems to fit more naturally how dart handle streams and asynchronous programming.
The dart:html library is used on the client-side and can be compiled to JavaScript.
Use dart:io for server-side code.
In a typical setup, you have a web server listening to WebSocket connections from the client, in which case you would use the one from dart:html. But of course you can also initiate WebSocket connections at the server if you ever need :)
dart:io is only available on the server
dart:html is only available in the browser
Related
I'm extremely new to all of this, but from my understanding, websockets allow for a bidirectional transfer of information between browsers. Vert.x is a library that allows for asynchronous I/O. And sockJS is a JavaScript library that attempts to use websockets for communication, and provides fallback options otherwise.
But if I'm writing something in Java using vert.x, I don't quite understand how the pieces fit together. Does vert.x actually support websockets? Or do I need a combination of vert.x and sockJS to make that happen?
HTTP(s) is a stateless protocol, which means that once its job is done it will be idle till the next job is given.
So lets take an example of chat application, assume A is chatting with B using HTTP protocol. B has sent a message which is in server, now until A refreshes the browser, B's message will not appear. That's stateless behavior.
Coming to sockets, which is not stateless. Sockets use ws protocol which is always connected to the server. Taking the same example, now if B sends a message, A's socket will fetch and display to the browser, without the need to refresh. That's how sockets work.
To serve a webpage you need an http server. Similarly to use sockets, sockets server is needed. Which is provided by Vert.x. So Vert.x will start socket server, your browser will listen to that server using clientside sock.js file.
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
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them. "ws:"
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Here are my random stabs in the dark
Applets sockets provided by Java (need java installed)
Flash sockets provided by Flash (need flash installed)
But about HTML5, Why are they called WebSockets if they aren't Sockets?
Is the websocket protocol so simple to implement that it is "almost"-sockets?
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them.
[Is the] websocket protocol so simple to implement that [it is] "almost"-sockets?
Allowing regular socket connections directly from the browser is never going to happen because it opens up a huge risk. WebSockets is about as close to raw sockets from the browser as you are going to get. The initial WebSockets handshake is similar to an HTTP handshake (allowing web servers to proxy/bridge it) and adds CORS type security. In addition, WebSockets is a message based transport (rather than streaming as raw TCP) and this is done using a two byte header on each message frame.
Even flash is not able to quite make raw TCP connections. Flash sockets also add CORS security, but instead of an in-band handshake, flash socket connections make a connection to port 843 on the target server to request a security policy file.
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Yes, you can use my websockify bridge/proxy which allows a WebSockets enabled browser to connect directly to a TCP socket via websockify.
But about HTML5, Why are they called WebSockets if they aren't Sockets?
WebSockets are a transport built on TCP sockets. After the handshake there is very minimal overhead (typically just a two byte header).
I can't improve on Kanaka's answers to your secondary questions, and I know this question is a year old. But for the main question, Is there any way of doing a pure socket connection from a web browser, to enliven webpages? There is a project called the Java / JavaScript Socket Bridge that might be what you (or anyone coming across this page from a Google search) are looking for. The advantage of this method over what others have mentioned is that it does not require either a client-side or a server-side service to be run. So, for instance, if you wanted to implement an IRC client purely in JavaScript but your web host does not allow you sufficient rights to proxy the connection, this Java applet would be the way to go. The only concern is making sure the client has Java installed and allowed.
You can just send data between a client and a server with WebSockets. Simply speaking, the only difference that WebSockets introduces is that the client:
adds some header bytes, like the type of data and the length
adds masks and encodes the data using them
The server also has to add header bytes, but does not need to encode the data.
If you implement the protocol correctly (server side, that is, since the browser already has an implementation), you can use it with ease to send text and binary data. (Although browser support is narrow, especially for the latter.)
The benefit of WebSocket is that it is HTTP based. You can use it also in environments there http proxies are used. Thus Websocket has a higher infrastructure compatibility as plain tcp.
Additionally http/WebSocket is providing you some features which you otherwise have to specify on your own:
Redirect
NAT keepalive
Multiplexing via URI
Framing
If you are asking for some data to be pushed from server it is widely termed as COMET or Reverse Ajax.
Web sockets is still not very popular as there are inherent firewall issues and minimal support yet from popular browsers.
You can take a look at http://www.ape-project.org/ as this is one of the most popular implementations (but native to unix/linux only for now. For windows they suggest using a virtual box or vmware based implementation)