Socket.Io 1.X: Use Websockets Only

Socket.io 1.x: use WebSockets only?

There are two types of "upgrades" happening with socket.io. First (in socket.io 1.0+), socket.io starts all connections with an http polling request and it may actually exchange some initial data with just an http request. Then, at some point after that, it will try to actually initiate a webSocket connection. the webSocket connection is done by sending a particular type of http request that specifies an upgrade: websocket header and the server can then respond appropriately whether it supports websocket or not. If the server agrees to the upgrade, then that particular http connection is "upgraded" to the webSocket protocol. At that point, the client then knows that webSocket is supported and it stops using the polling http requests, thus completing its upgrade to webSocket.

You can prevent the initial http polling entirely by doing this on the client:

var socket = io({transports: ['websocket'], upgrade: false});

This will prevent polling connections from your own cooperating clients. If you want to prevent any clients from ever using polling, then you can add this to the server:

io.set('transports', ['websocket']);

But, if you set this on the server, socket.io clients that are initially connecting with http polling will not work at all. So, this should only be matched with the right settings in the client such that the client never starts with polling.

This will tell both ends that you only want to use webSockets and socket.io will skip the extra http polling at the beginning. Fair warning, doing this requires webSocket support so this rules out compatible with older versions of IE that didn't yet support webSocket. If you want to retain compatibility, then just let socket.io do it's thing with a couple http requests initially.


Here's more info on the protocol upgrade from http to webSocket.

The webSockets protocol initiates EVERY webSocket with an HTTP connection. That's the way all webSockets work. That HTTP connection contains some headers on it that indicate that the browser would "like" to upgrade to the webSockets protocol. If the server support that protocol, then it responds telling the client that it will upgrade to the webSocket protocol and that very socket then switches from the HTTP protocol to the webSocket protocol. This is how a webSocket connection is designed to work. So, the fact that you see your webSocket connection starting with an HTTP connection is 100% normal.

You can configure socket.io to NEVER use long polling if that makes you feel better, but this will not change the fact that the webSocket connection will still start with an HTTP connection that is then upgraded to the webSocket protocol and it will not improve the efficiency of operation in modern browsers that support webSockets. It will, however make it so that your connection will not work in older browsers.

NodesJS SocketIO - How can I make sure websockets are being used?

You seem to be using both WebSocket and Socket.io and it can cause conflicts. You should choose one and stick to it. If you're sure that your client will use WebSocket then there is no need to use Socket.io at all. Just use WebSocket ad you will have to worry about the AJAX, comet, long-polling workarounds.

This is an example server-side code using WebSocket:

var path = require('path');
var app = require('express')();
var ws = require('express-ws')(app);
app.get('/', (req, res) => {
console.error('express connection');
res.sendFile(path.join(__dirname, 'ws.html'));
});
app.ws('/', (s, req) => {
console.error('websocket connection');
for (var t = 0; t < 3; t++)
setTimeout(() => s.send('message from server', ()=>{}), 1000*t);
});
app.listen(3001, () => console.error('listening on http://localhost:3001/'));
console.error('websocket example');

As you can see this is pretty simple.

See code examples in those answers for more info:

  • Differences between socket.io and websockets
  • Socket.io 1.x: use WebSockets only?
  • NodeJS Websocket (ws) Callback

Connecting to socket.io 1.x manually using websockets, capacity testing

I ended up setting for using the socket.io-client npm package which has the ability to connect to a new session on every connection. I found an example benchmark in this issue.

There is not so much need for me to manually connect to socket.io using pure websockets and HTTP, but thanks to Yannik for pointing out the parser in use. The spec of the inner workings of v1.x can be found here.

Thanks!

Differences between socket.io and websockets

Its advantages are that it simplifies the usage of WebSockets as you described in #2, and probably more importantly it provides fail-overs to other protocols in the event that WebSockets are not supported on the browser or server. I would avoid using WebSockets directly unless you are very familiar with what environments they don't work and you are capable of working around those limitations.

This is a good read on both WebSockets and Socket.IO.

http://davidwalsh.name/websocket

flask-socketio: limit transport to websocket only

See this post - Socket.io 1.x: use WebSockets only?

It looks like you can't get rid of the original HTTP call, but you can tell the client not to use long-polling.

var socket = io({transports: ['websocket']});

I can't find a way to disable it from the server-side with Flask-SocketIO.

Websockets transport only in Socket.io 1.3.4

All webSocket connections start with an HTTP request. That's how the specification works for webSocket. The client requests an upgrade to the webSocket protocol in that first HTTP request and, if the server agrees, then the socket is "upgraded" to the webSocket protocol.

In case the server does not support webSocket and will not agree to the upgrade, socket.io also sends polling parameters with that first http request so if it does not switch to webSocket, then it will immediately start with http polling.

So, the short answer is that if you look at the network trace, you may think it's starting with http polling, but that's really just the HTTP request that initiates a webSocket connection. This is the way it is supposed to be.

If you want to see more about how a webSocket connection gets established, you can read this nice summary.

Here's a request to start a webSocket connection:

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

And, here's a server response to agree to upgrade to a webSocket connection:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

This is how the webSocket protocol was designed to make it possible for the same networking infrastructure to support both HTTP connections and webSocket connections and to allow the client to query the server to see if it supports webSocket.

After a successful "upgrade", then only the webSocket protocol is spoken on this socket.

When does socket.io use polling instead of websockets?

The only time a client will downgrade to ajax polling (assuming your server does support it which it does) is when the browser client doesn't support webSockets (e.g. a very old client) or perhaps if some proxy in the client path doesn't support webSockets.

webSockets are supported in IE10+ and all recent releases of the other browsers.

So, practically speaking, it's really just IE8 or IE9 or a badly behaved proxy where you might not see client webSocket support.

There are no other conditions (other than lack of support) that will "knock" a connection down to polling.


You can temporarily test your application with polling by only passing in the xhr-polling transport option when connecting from the client to tell the client that that is the only transport option that is allowed.


Keep in mind that all webSocket connections start with an HTTP request that is then "upgraded" to the webSocket protocol if both sides agree so if you're looking at the network trace from your browser, you should see each webSocket connection start with an HTTP request - that is normal. And, in the latest version of socket.io, it may actually exchange a few data packets with the polling transport before it successfully tries and switches to an actual webSocket.



Related Topics



Leave a reply



Submit