Socket.io-client: Transport defaults to polling instead of websocket?

Created on 11 Sep 2015 · 9Comments · Source: socketio/socket.io-client

Line 1613 of socket.io.js reads:
this.transports = opts.transports || ['polling', 'websocket'];

Why isn't the order ['websocket', 'polling']?

On the client side I'm doing:
var socket = io.connect(url);

Then on the server side, i did:
io.on('connection', function(socket){
console.log(socket);
});

The handshake part looks like:

handshake: 
   { headers: 
      { 'user-agent': 'node-XMLHttpRequest',
        accept: '*/*',
        host: 'localhost:8081',
        connection: 'close' },
     time: 'Fri Sep 11 2015 16:04:39 GMT-0400 (EDT)',
     address: '::ffff:127.0.0.1',
     xdomain: false,
     secure: false,
     issued: 1442001879771,
     url: '/socket.io/?EIO=3&transport=polling&t=1442001879749-0&b64=1',
     query: { EIO: '3', transport: 'polling', t: '1442001879749-0', b64: '1' } }

Does this mean it's using polling instead of websocket?

I tried to set the transport to 'websocket' explicitly, and the handshake part changed to the following which seems correct:
var socket = io.connect(url,{transports:['websocket']});

handshake: 
   { headers: 
      { connection: 'Upgrade',
        upgrade: 'websocket',
        host: 'localhost:8081',
        origin: 'localhost:8081',
        'sec-websocket-version': '13',
        'sec-websocket-key': 'MTMtMTQ0MjAwMTUxNDcyNA==' },
     time: 'Fri Sep 11 2015 15:58:34 GMT-0400 (EDT)',
     address: '::ffff:127.0.0.1',
     xdomain: true,
     secure: false,
     issued: 1442001514739,
     url: '/socket.io/?EIO=3&transport=websocket',
     query: { EIO: '3', transport: 'websocket' } }

Source

napalm272

👍4

Most helpful comment

+1
I prefer the idea of "downgrade" instead of "upgrade".Currently most browsers support websocket well.Initially connecting with websocket will improve performance and save resources.

stackOverMind on 20 Oct 2015

👍14

All 9 comments

+1
I prefer the idea of "downgrade" instead of "upgrade".Currently most browsers support websocket well.Initially connecting with websocket will improve performance and save resources.

stackOverMind on 20 Oct 2015

👍14

The reason of upgrade is the following.

Socket.IO never assumes that WebSocket will just work, because in practice there’s a good chance that it won’t. Instead, it establishes a connection with XHR or JSONP right away, and then attempts to upgrade the connection to WebSocket. Compared to the fallback method which relies on timeouts, this means that none of your users will have a degraded experience.

http://socket.io/blog/introducing-socket-io-1-0/

nkzawa on 27 Nov 2015

👍5

@nkzawa
I understand why the upgrade approach is preferred, and it is a very nice feature.
But it is not always needed: in controlled enterprise environments the downgrade approach makes more sense, and I would say that forcing web socket as the only allowed transport is the best way of optimizing the performance.

I tried to force the transport to web socket both on client and server by passing this option:
{ transports: ["websocket"] }

This seems to work and I only have one web socket connection to the server, but I noticed that a polling is also being done which obviously fails on every try:
Request URL:http://localhost:4000/socket.io/?EIO=3&transport=polling&t=L8RaD0p
{ code: 0, message: "Transport unknown" }

Is there any viable solution at the moment to change this upgrade approach to downgrade?

sirudog on 7 Jan 2016

Never mind, it was my code which did that extra polling from a different class where I also used socket.io. So using opts which restricts the transports to websocket when I connect does what I wanted.

sirudog on 7 Jan 2016

@sirudog
You can try this: { transports: ['websocket', 'polling'] }

poppowerlb2 on 11 Jan 2016

👍5

Thanks @poppowerlb2 (no more traffic like him in my network tab). Even if my browser is up to date, i see that socket-io-client prefers polling.

jy95 on 25 Apr 2017

Doesn't this upgrade approach exclude some servers? I'm attempting to use socket.io with a node-red server and I'm not yet able to establish a connection. Of course, it works fine with plain websockets.

rm-rf-etc on 8 Aug 2017

I also think it's preferable that socket.io tries websockets even if polling won't works.

yoch on 18 Feb 2018

+1
I prefer the idea of "downgrade" instead of "upgrade".Currently most browsers support websocket well.Initially connecting with websocket will improve performance and save resources.

`
const client = io('https://io.yourhost.com', { // WARNING: in that case, there is no fallback to long-polling transports: [ 'websocket' ] // or [ 'websocket', 'polling' ], which is the same thing})

https://socket.io/docs/using-multiple-nodes/
`