Socket.io-client: ¿Transporte predeterminado a sondeo en lugar de websocket?

Creado en 11 sept. 2015 · 9Comentarios · Fuente: socketio/socket.io-client

La línea 1613 de socket.io.js dice:
this.transports = opts.transports || ['polling', 'websocket'];

¿Por qué el pedido no es ['websocket', 'polling']?

En el lado del cliente, estoy haciendo:
var socket = io.connect (url);

Luego, en el lado del servidor, lo hice:
io.on ('conexión', función (enchufe) {
console.log (enchufe);
});

La parte del apretón de manos se ve así:

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' } }

¿Significa esto que está usando sondeo en lugar de websocket?

Intenté configurar el transporte en 'websocket' explícitamente, y la parte del apretón de manos cambió a lo siguiente, que parece correcto:
var socket = io.connect (url, {transportes: ['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' } }

Fuente

napalm272

👍4

Comentario más útil

+1
Prefiero la idea de "degradar" en lugar de "actualizar". Actualmente, la mayoría de los navegadores son compatibles con websocket. Inicialmente, conectarse con websocket mejorará el rendimiento y ahorrará recursos.

stackOverMind en 20 oct. 2015

👍14

Todos 9 comentarios

stackOverMind en 20 oct. 2015

👍14

La razón de upgrade es la siguiente.

Socket.IO nunca asume que WebSocket simplemente funcionará, porque en la práctica hay una buena posibilidad de que no funcione. En cambio, establece una conexión con XHR o JSONP de inmediato y luego intenta actualizar la conexión a WebSocket. En comparación con el método alternativo que se basa en tiempos de espera, esto significa que ninguno de sus usuarios tendrá una experiencia degradada.

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

nkzawa en 27 nov. 2015

👍5

@nkzawa
Entiendo por qué se prefiere el enfoque de actualización, y es una característica muy agradable.
Pero no siempre es necesario: en entornos empresariales controlados, el enfoque de degradación tiene más sentido, y yo diría que forzar el web socket como el único transporte permitido es la mejor manera de optimizar el rendimiento.

Intenté forzar el transporte al socket web tanto en el cliente como en el servidor pasando esta opción:
{ transports: ["websocket"] }

Esto parece funcionar y solo tengo una conexión de socket web al servidor, pero noté que también se está realizando un sondeo que obviamente falla en cada intento:
Request URL:http://localhost:4000/socket.io/?EIO=3&transport=polling&t=L8RaD0p
{ code: 0, message: "Transport unknown" }

¿Existe alguna solución viable en este momento para cambiar este enfoque de actualización a degradación?

sirudog en 7 ene. 2016

No importa, fue mi código el que hizo ese sondeo adicional de una clase diferente donde también usé socket.io. Entonces, usar opciones que restringen los transportes a websocket cuando me conecto hace lo que quería.

sirudog en 7 ene. 2016

@sirudog
Puedes probar esto: {transportes: ['websocket', 'polling']}

poppowerlb2 en 11 ene. 2016

👍5

Gracias @ poppowerlb2 (no más tráfico como él en mi pestaña de red). Incluso si mi navegador está actualizado, veo que socket-io-client prefiere el sondeo.

jy95 en 25 abr. 2017

¿Este enfoque de actualización no excluye algunos servidores? Estoy intentando usar socket.io con un servidor node-red y todavía no puedo establecer una conexión. Por supuesto, funciona bien con websockets simples.

rm-rf-etc en 8 ago. 2017

También creo que es preferible que socket.io pruebe websockets incluso si el sondeo no funciona.

yoch en 18 feb. 2018

+1
Prefiero la idea de "degradar" en lugar de "actualizar". Actualmente, la mayoría de los navegadores son compatibles con websocket. Inicialmente, conectarse con websocket mejorará el rendimiento y ahorrará recursos.

'
const client = io ('https://io.yourhost.com', {// ADVERTENCIA: en ese caso, no hay alternativa a los transportes de sondeo largo: ['websocket'] // o ['websocket', ' polling '], que es lo mismo})

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