As their faq states, socket.io supports cross-domain connections on every browser.
Could someone tell me, if cross-domain-communications then uses a particular transport mechanism like long-polling, or does it work with all supported mechanisms.
Annother thing is var socket = io.connect('http://localhost');. This is used the client to connect to the socket.io server. As this establishes a connection by WebSockets, longpolling, etc.. the above connect method itself uses a regular http request. Would not at least this request violate the same origin policy?
I just tested it in IE 8 and FireFox 14:
Cross-domain works for
jsonp
xhr-polling
Websocket
flashsocket
Cross-domain does not work for
htmlfile
htmlfile btw in general only works in IE, whereas websocket does not work in IE (< 10). flashsocket does not work in browsers that support websocket, which is why I tested that one in IE8 only.
Related
We are using IIS and ISAPI DLL's to deliver our web application. We can see the websocket upgrade request coming from the browser in our ISAPI application. We could accept the request and pass the connection to a thread to continue the conversation. The thread would now be the "websocket server" so in this sense we are able to handle incoming http (and https on 443) then switch from http to websocket, is that right?
I am assuming Microsoft's implementation of websockets only works with asp.net?
Some people have said to me "put the websocket server on a different port and have the javascript connect to that port." But, then the websocket server is not using HTTPS (SSL).
For example:
var socket = new WebSocket('ws://echo.websocket.org');
I have lots of books and examples but this simple issue is eluding me.
The thread would now be the "websocket server" so in this sense we are able to handle incoming http (and https on 443) then switch from http to websocket, is that right?
Yes, if the client side send the request which contains the Upgrade: websocket, the websocket serve will switch from http to websocket.
I am assuming Microsoft's implementation of websockets only works with asp.net?
If you means the websocket .net library, it will just work with .net application like asp.net, it is developed based on the .net framework.
For example: var socket = new WebSocket('ws://echo.websocket.org');
As far as I know, the websocket also contains the secure connection like https.
Like below image shows:
More details about the difference between http and websocket, you could refer to below article:
https://developerinsider.co/difference-between-http-and-http-2-0-websocket/
This question already has answers here:
WebSockets protocol vs HTTP
(6 answers)
Closed 8 years ago.
when I read engine io protocol, I found it use polling to establish the connection and then upgrade the transport to websocket, I don't know why ? could you give me some idea?
It's because the WebSocket upgrade could fail, so having polling as a fallback mechanism is useful.
It doesn't really use polling. The initial HTTP url may look like it's a setup for polling, but that will go into play only if the server doesn't agree to upgrade the connection to the webSocket protocol.
A socket.io connection starts with a single TCP connection which is an HTTP request with certain webSocket headers set and then when the server responds that the webSocket protocol is supported, the connection is "upgraded" from HTTP to webSocket and both sides switch the protocol being used from HTTP to webSocket. This is how the webSocket protocol is specified.
If the client/server combination does not support webSocket, then and only then does socket.io resort to using long polling.
This particular design allows both webSocket and HTTP to share the same port and the socket.io design allows for a graceful fallback to long-polling if both sides don't agree on a webSocket upgrade.
engine.io/socket.io 1.x+ starts with polling first because that pretty much always works with all types of clients, allowing them to get connected very quickly. Then in the background, attempts to upgrade the connection are made (to WebSockets or whatever else). That way if the connection upgrades fail, nothing is lost because the polling is still working like before, so there is no down time.
The reason for this change from the old behavior of downgrading instead of upgrading is that WebSockets can be troublesome to get going correctly in some situations (e.g. problems with load balancers, proxies, etc.) and even if they do get connected there can be some extra delays involved. Also using the flash fallback for WebSockets would take some time to get connected because it involves extra roundtrips and some additional delays.
Faye supports cross-domain subscription. Here is an excerpt from their docs:
Cross-domain operation
Faye clients and servers transparently support
cross-domain communication, so your client can connect
to a server on any domain you like without further configuration.
Anyone knows how it achieves it?
Faye uses JSONP to send a handshake request to the server when it's cross-domain, as the author of Faye explains in his reply here. It then selects a new transport from a list, in order of preference: WebSocket, EventSource, XHR, CORS and JSON-P. Note that WebSockets, once established, can also work cross-domain as previously discussed here.
I have an existing websocket server which serves json over websockets for IM on some non-http/s port.
This works fine for browsers which support websocket protocol but leaves a lot of other browsers from using the feature.
I was reading up on socket.io and nodejs and was thinking of adding a proxy using socket.io and nodejs in front of the websocket server to handle all websocket requests. Since socket.io supports fallback using flash websockets or long polling, I was hoping that using socket.io on client side will allow support for all older browsers as well.
So, my questions are,
Is the above approach feasible?
How does the fallback to long polling have to be handled in nodejs? Is it handled automatically or needs to be implemented?
Any existing resources which might help me out.
Thanks
It can be made feasible. However I suggest using NodeJS and Socket.IO for both your non-http request and http request for browsers. NodeJS can handle them very easily.
Socket.IO handles fallback automatically.
A simple chat system example here for http.
I was looking into Faye and socket-IO, socket-IO degrades to websockets, flash sockets, JSONP and such, but what are all the supported transport methods faye supports? Does it support flashsockets? Also does it support Multi-channels?
protocols folder on github
Websocket, xhr, JSONP.
It also has CORS which seems to be something to do with Cross origin resource sharing
No sign of flash sockets so far.
Faye uses WebSocket, XMLHttpRequest, CORS and JSON-P in order of preference. Each client can subscribe to as many channels as you like.