Socket.io: Hoja de ruta para v3

Parece un gran plan.

Estoy cambiando de nodejs a golang y descubrí que no hay una implementación de socket.io 2.
https://github.com/googollee/go-socket.io/issues/188

¿Qué opinas del soporte del servidor golang para v3? Estaré feliz de participar en este desarrollo.

@theromis , ¿está hablando de un cliente golang (que se conectará al servidor Node.js) o de un servidor golang real? (Creo que también se ha hecho algo de trabajo aquí: https://github.com/graarh/golang-socketio)

@darrachequesne Gracias por la respuesta rápida, sí, estoy hablando del golang-socketio del lado del servidor.
El proyecto mencionado por usted está casi muerto (último compromiso más de un año).
https://github.com/googollee/go-socket.io proyecto en busca de mantenedor.
Y ninguno de ellos es compatible con socket.io v2.
Pensé que los mejores desarrolladores originales de nodejs socketio podrían estar interesados ​​​​en el desarrollo de golang también :)

El cliente Java actualizado también sería bueno.

Un paquete socket.io para el lado del servidor rápido como https://github.com/vapor también sería muy bueno ya que ya hay un cliente rápido.

Parece que si socket.io del lado del servidor se escribirá en algún idioma nativo como C / C ++, se puede usar en todas partes, incluidos nodejs, golang, java, rust y lo que sea ...
¿Qué tiene de malo este enfoque?
Mi opinión personal, socket.io es como el estándar de facto para el mundo moderno. ¿Por qué no hacerlo ideal?

Una cosa que siempre me ha molestado sobre socket.io que podría abordarse en la próxima versión importante podría ser https://github.com/socketio/socket.io/issues/2124 y https://github.com /socketio/socket.io/issues/2343

Ha habido una inconsistencia histórica en el manejo de espacios de nombres y middlewares.
Además, el client que emite un evento reconnect tiene más sentido en mi opinión, después de que se conecta al namespace en lugar de ser solo el evento de reconexión del Gerente... Por ejemplo , si hay algún error de autenticación en un middleware de espacio de nombres secundario, el cliente aún obtendrá un evento de reconexión que creo que es contrario a la intuición.

Desde la versión 10.5 del nodo, hay un nuevo Worker Threads, que actualmente se encuentra en estado experimental, pero cuando se lanzó, creo que puede ser una mejor manera de usar socket.io en lugar de usar el servidor redis.

Pro:

• menos dependencia (redis)
• soporte nativo de subprocesos múltiples
• mas control

Estafa:

• solo funcionará desde esa versión de nodejs que libere el subproceso de trabajo (10.x || 11). Pero esto se puede manejar.

@Dos es interesante! Funcionaría para los trabajadores en el mismo host, pero ¿qué pasa con múltiples hosts?

@perrin4869 buena idea :+1:

Dejé muchas ideas aquí: #3311 por favor lea :) Cerraré esa y continuaré la discusión aquí.

@MickL , ¿tendría algo de tiempo para migrar el repositorio socket.io a Typescript, como ejemplo?

Me temo que mi conocimiento de la tecnología de redes y la seguridad de la información es limitado. Confío en frameworks de alto nivel como Express o Socket.io.

Por lo que veo, socket.io ya está escrito OOP y está bien documentado, por lo que sería obvio simplemente portarlo. Mi idea era ir lo más modular posible para que alguien como yo pudiera contribuir de manera más fácil y el cliente se pudiera sacudir. También volverse más reactivo podría ser una idea para simplificar las cosas. De todos modos, no estoy lo suficientemente metido en el código, por lo que ambas ideas posiblemente no tengan sentido en este proyecto.

@darrachequesne es una buena pregunta. voy a pensar en ello.

Requiere Nodejs 8 y superior, ya que las versiones anteriores están en mantenimiento en el mejor de los casos, consulte https://nodejs.org/en/about/releases/ , como mínimo, nodejs 4 debe eliminarse (me di cuenta de .travis.yml que admite eso)

¿Ha comenzado el trabajo relacionado con 3.0 en alguna sucursal/repositorio? Solo verificando si hay un lugar para mantenerse informado sobre cómo va o cómo contribuye.

Me gustaría ver un soporte mejorado para el manejo de errores en el lado del servidor. Esto se ha mencionado en algunos otros problemas, pero más específicamente, sería genial si:

1. Hubo soporte para un middleware de manejo de errores personalizado además del predeterminado. Esto podría parecerse a Express's (que se puede agregar como el último en la cadena de app.use() , similar a socket.use() , middlewares): https://expressjs.com/en/guide/error -manejo.html

El problema, actualmente, es que no hay forma de agregar ningún tipo de seguimiento o registro a un error una vez que ha sido nexted .

1. Además, dado que el espacio de nombres de 'error' está en la lista negra, el cliente no escuchará socket.emit('error', err) ), no puedo emit un error de algún lugar del servidor que no tiene fácil acceso a next() (es decir, desde dentro de socket.on('event') ). Esto dificulta la creación de una solución uniforme para el manejo de errores.

2. next(err) debería enviar un objeto Error en lugar de una cadena. Entiendo que hay una solución para esto (https://github.com/socketio/socket.io/issues/3371) agregando una propiedad mágica .data a cualquier objeto que llames next() en. Sin embargo, esto no está documentado y no es intuitivo.

En términos generales, next(err) parece una caja negra innecesaria con una capacidad de manejo de errores muy limitada.

¡Gracias por su arduo trabajo y por seguir haciéndolo!

@darrachequesne ¿ Alguna actualización sobre v3 siendo una realidad? No he visto ningún progreso en esto desde 2018.

Una breve actualización: mi contrato actual se actualizó recientemente y debería poder dedicar un día por semana (1/5) al mantenimiento del proyecto. Por lo tanto, el trabajo en v3 debería reanudarse en breve.

Realmente dispuesto a ayudar en este proyecto de una forma u otra.

Si hay una manera de identificar cómo puedo hacer esto, hágamelo saber. ¡Simplemente no quiero arreglar las cosas para que no se fusionen! Por lo tanto, preferiría esperar alguna orientación, si se necesita ayuda. Salud

• compresión (gzip, zlib, defalte/inflate)
• mecanismo de reelaboración de envío de datos binarios (2 paquetes ahora... ws texto y ws binario)
• enviar metadatos en la conexión (¿usar compresión?)
• los codificadores/codificadores como complementos incluyen uno personalizado (paquete de mensajes, protobuf, etc.), podríamos usar genéricos si el código se reescribirá a mecanografiado
• fijación de certificados (servidor/lado del cliente)

@blackkopcap

compresión (gzip, zlib, defalte/inflate)

La compresión ya es compatible (https://github.com/socketio/engine.io/blob/a05379b1e87d2e4cde40d3e30b134355883f4108/lib/transports/polling.js#L249-L298). Sin embargo, la compresión WebSocket ( perMessageDeflate ) estará deshabilitada de forma predeterminada en v3, ya que requiere mucha memoria adicional.

mecanismo de reelaboración de envío de datos binarios (2 paquetes ahora... ws texto y ws binario)

Totalmente de acuerdo. Tarjeta añadida aquí

enviar metadatos en la conexión (¿usar compresión?)

No estoy seguro de entender. ¿Podría explicar el caso de uso?

los codificadores/codificadores como complementos incluyen uno personalizado (paquete de mensajes, protobuf, etc.), podríamos usar genéricos si el código se reescribirá a mecanografiado

Ya debería poder proporcionar su propio analizador, como socket.io-msgpack-parser

fijación de certificados (servidor/lado del cliente)

:+1:, añadido aquí .

@michaelegregious

1. Hubo soporte para un middleware de manejo de errores personalizado además del predeterminado. Esto podría parecerse a Express's (que se puede agregar como el último en la cadena de app.use() , similar a socket.use() , middlewares): https://expressjs.com/en/guide/error -manejo.html

Eso sería genial de verdad. Agregado aquí

1. Además, dado que el espacio de nombres de 'error' está en la lista negra (el cliente no escuchará socket.emit('error', err) ), no puedo emit un error de algún lugar del servidor que no tiene fácil acceso a next() (es decir, desde dentro de socket.on('event') ). Esto dificulta la creación de una solución uniforme para el manejo de errores.

No estoy seguro de lo que podríamos hacer. ¿Tienes una sugerencia?

1. next(err) debería enviar un objeto Error en lugar de una cadena. Entiendo que hay una solución para esto (https://github.com/socketio/socket.io/issues/3371) agregando una propiedad mágica .data a cualquier objeto que llames next() en. Sin embargo, esto no está documentado y no es intuitivo.

Totalmente de acuerdo :+1: , añadido aquí

Ya lanzamos Engine.IO v4, que se incluirá en Socket.IO v3. Puede encontrar las notas de la versión aquí .

He agregado lo que pude encontrar en este hilo al proyecto aquí , para dar una visión general del progreso. ¡No dudes en comentar!

Esto es lo que tenía en mente para arreglar https://github.com/socketio/socket.io/issues/2124

El cliente ahora enviará un paquete CONNECT cuando desee obtener acceso al espacio de nombres predeterminado ( / ) (no más conexiones implícitas).

Lo que significaría que los middlewares que están registrados para el espacio de nombres predeterminado ya no se aplicarán a los clientes que desean obtener acceso a un espacio de nombres no predeterminado.

// server-side
io.use((socket, next) => {
  // not triggered anymore
});

io.of('/admin').use((socket, next => {
  // triggered
});

// client-side
const socket = io('/admin');

En el lado del cliente, creo que también deberíamos hacer una distinción clara entre la opción query para el Administrador (que se incluye en los parámetros de consulta) y la opción query para el Socket (que se envía en el paquete CONNECT ).

Ahora mismo:

const socket = io('/admin', {
  query: {
    abc: 'def'
  }
});

da como resultado solicitudes como GET /socket.io/?transport=polling&abc=def y también un paquete CONNECT como { "type": 0, "nsp": "admin?abc=def"}

Además, dado que no hay un paquete CONNECT para el espacio de nombres predeterminado, el query del Socket se ignora actualmente en ese caso.

Propongo cambiarle el nombre a authQuery en su lugar.

const socket = io({
  query: {
    abc: 'def'
  },
  authQuery: {
    abc: '123'
  }
});

daría como resultado solicitudes como GET /socket.io/?transport=polling&abc=def y un paquete CONNECT como { "type": 0, "nsp": "/", "data": { abc: '123' } }

@perrin4869 ¿tendría sentido?

Editar: con respecto a las compensaciones, habrá más solicitudes HTTP en el inicio...

Server > Client: Engine.IO handshake
Client > Server: Socket.IO connect
Server > Client: Socket.IO connect

Si bien actualmente tenemos:

// without middleware on the default namespace (only 1 GET request)
Server > Client: Engine.IO handshake + Socket.IO connect
// with at least a middleware (2 GET requests)
Server > Client: Engine.IO handshake
Server > Client: Socket.IO connect

@darrachequesne ¡ Gracias por tomar esto en consideración! Es bueno cerrar un poco aquí, finalmente pude simplificar el código que tenía en ese entonces: D
Ha pasado mucho tiempo, así que no recuerdo exactamente, pero esto suena como la solución que buscaba.
Por curiosidad, ¿cuál es el motivo de las compensaciones?

Siguiendo la idea de cómo funciona js Shapes: https://web.archive.org/web/20200201163000/https ://mathiasbynens.be/notes/shapes-ics. Para mejorar el rendimiento, ¿no sería mejor usar arreglos para almacenar referencias para conexiones de socket? Más y más conexiones, innumerables ids y el uso de objetos para hacer esto con cada nueva conexión, se genera una nueva forma y se consume más memoria, dependiendo de la vida útil de un nodo y la cantidad de conexiones que pueda tener, esto probablemente tendrá algún impacto negativo en el rendimiento.

@perrin4869 las compensaciones provienen de la implementación actual, ya que primero establecemos la conexión Engine.IO y luego procedemos con la conexión Socket.IO. Lo que da, si el transporte de sondeo largo HTTP está habilitado (que es el valor predeterminado):

• una solicitud HTTP GET para recuperar el protocolo de enlace Engine.IO
• una solicitud HTTP POST para enviar el paquete Socket.IO CONNECT
• una solicitud HTTP GET para recuperar el paquete Socket.IO CONNECT del servidor
• y luego la actualización a WebSocket

Pero seguro que se puede mejorar. Como referencia, el cambio se implementó aquí y aquí .

Además, el evento reconnect ya no será emitido por la instancia de Socket (del lado del cliente) ( aquí ).

@ferco0 ahora usaremos Map en lugar de un objeto simple (https://github.com/socketio/socket.io/commit/84437dc2a682add44bb57d03f703cfc955607352). ¿Aún se aplica su comentario, en ese caso?

Se han publicado [email protected] y [email protected] :fire:

Algunas notas:

• la API pública no cambia mucho (aunque se han eliminado algunos métodos, consulte aquí y aquí como referencia)
• el código base se migró a TypeScript, pero faltan algunos tipos, especialmente en el lado del cliente.
• Se han incluido los cambios importantes en Engine.IO v4 (enumerados aquí ).
• el tamaño del paquete del cliente ha aumentado un poco, a pesar de tener menos dependencias, profundizaré en esto

¡Cualquier comentario es bienvenido!

@darrachequesne está bien.

@darrachequesne Muchos proyectos de código abierto de npm intentan disminuir la cantidad de dependencias. Es algo así como una tendencia dentro de la comunidad. La razón principal es que muchas organizaciones requieren verificar las licencias de todas las dependencias utilizadas cuando se usan en proyectos, para no tener problemas legales. Tener menos dependencias ayuda con esto, por supuesto. Como ejemplo, Helmet (un excelente paquete de seguridad para el servidor web Express) pasó a una instalación de dependencia cero en la última versión 4.0.

Con eso en mente, ¿hay algún plan para disminuir la cantidad de dependencias en socket.io en la versión 3?

@thernstig ¡ esa es una buena pregunta! De hecho, hemos intentado reducir el número de dependencias en Socket.IO v3:

npm i [email protected] => 48 packages
npm i [email protected] => 33 packages

npm i [email protected] => 37 packages
npm i [email protected] => 20 packages

Aquí está el árbol de dependencia para el servidor:

[email protected]
├── [email protected]
├─┬ [email protected]
│ └── [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
│ │ │ └── [email protected]
│ │ └── [email protected]
│ ├── [email protected] deduped
│ ├── [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ └── [email protected]
│ ├── [email protected] deduped
│ ├── [email protected]
│ └── [email protected]
├── [email protected]
├─┬ [email protected]
│ ├── @types/[email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected] deduped
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├─┬ [email protected]
│ │ │ └─┬ [email protected]
│ │ │   └── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ └── [email protected]
│ ├── [email protected]
│ └── [email protected] deduped
└─┬ [email protected]
  ├── [email protected] deduped
  └── [email protected] deduped

Creo que solo necesitamos la carpeta dist/ socket.io-client del paquete socket.io-client, por lo que podría tener sentido crear un socket.io-client-dist sin dependencias. ¿Qué piensas?

Nota: enchufe. [email protected] y zócalo. [email protected] han sido publicados

He agregado algunos ejemplos con módulos ES y TypeScript .

@darrachequesne eso lo dejo totalmente a su criterio 😄

@michaelegregious con respecto a su comentario , sé que ha pasado bastante tiempo, pero ¿tenía en mente una API específica?

Acepto que la API actual podría mejorarse. Se implementó como una forma de tener un oyente general (discutido aquí ), y no con el manejo de errores en mente.

También podríamos agregar una forma de advertir a los usuarios sobre eventos no controlados (respuestas 404 en Express, http://expressjs.com/en/starter/faq.html#how-do-i-handle-404-responses).

¡¡@darrachequesne genial escuchar que estás trabajando en la próxima versión de socket.io!! Gracias de antemano por todo su trabajo en esta biblioteca.

Actualmente estoy probando socket. [email protected] y zócalo. [email protected] y estoy tratando de usar la nueva sintaxis para unirme a una habitación y emitir a los enchufes de esa habitación.

No puedo hacer que el servidor emita al socket del cliente usando su ejemplo en el archivo de registro de cambios.

socket.join("room1"); io.to("room1").emit("hello");

Se adjuntan capturas de pantalla que muestran el archivo socket js que se usa en el cliente y el código para el servidor node.js

archivo js del lado del cliente

evento socket.on del lado del cliente

sintaxis de unión del lado del servidor dentro de io.on("conectar",

Probé todos los métodos en la última captura de pantalla para que se emita al cliente y nada funciona.

Por favor, hágamelo saber si necesita más información.

Gracias

@darrachequesne Bajé a 3.0.0-rc2 y me uní a la sala usando el método de devolución de llamada llamado "room1" que se activa pero ninguno de los eventos de emisión se envía al cliente

socket.join("room1", () => { console.log('old way to join'); io.to("room1").emit("hello", {}); io.in("room1").emit("hello", {}); });

También desinstalé 3.0.0-rc2 e instalé socket.io 2.3.0 para Servidor y Cliente y confirmé que el código anterior funciona como se esperaba. Entonces creo que algo está roto con las versiones 3.0.0 rc

@szarkowicz Hmm... No puedo reproducir el comportamiento que estás describiendo: https://github.com/socketio/socket.io-fiddle/tree/issue/v3

El siguiente código parece funcionar como se esperaba:

socket.join("room1");

io.to("room1").emit('hello', 1, '2', {
  hello: 'you'
});

¿Te sale algún error en la consola? ¿Obtiene un evento connect en el lado del cliente?

@darrachequesne gracias por confirmar. Lo he rastreado hasta el uso de redisAdapter que causa el problema. Una vez que comento el siguiente código, la versión rc3 de socket.io funciona como se esperaba.

let redisAdapter = require('socket.io-redis');
io.adapter(redisAdapter({ host: 'localhost', port: 6379 }));

¿Has probado a usar redis con la v3 de socket.io?

Gracias

@szarkowicz sí, tiene toda la razón, el adaptador Redis debe actualizarse para cumplir con Socket.IO v3, se actualizará justo después del lanzamiento de 3.0.0 (que debería ser pronto).

En cualquier caso, muchas gracias por los comentarios :+1:

@darrachequesne vale, suena bien!!! Simplemente no lo usaré por ahora y continuaré probando sin él.

¿Tiene un momento en el que cree que se lanzará v3?

No se preocupe, ¡gracias nuevamente por comunicarse conmigo y por trabajar en todas las mejoras para la próxima versión!

@darrachequesne ¡Muchas gracias por estas actualizaciones! Lo siento por mi respuesta tardía! No estamos usando socket.io en mi proyecto actual (aunque podemos integrarlo en el futuro), pero la solución que usé en mi último proyecto fue usar socket.emit('err', err) en lugar de usar el espacio de nombres privilegiado socket.emit('error', err) .

Esta es la nota que puse en el archivo Léame de nuestra aplicación para explicar el problema:

#### Error Handling Patterns
Most of the communication between client and server in the app happens via `socket.io`. For server-side error-handling, `socket.io` exposes [Express](https://expressjs.com/en/guide/error-handling.html)-like middleware via `socket.use(socket, next)`. Middlewares can be chained to separate concerns for authentication, logging, etc.

Unlike `Express`, however, `socket.io`'s native `next(err)` does not support addition of custom error handlers. Calling `next(err)` immediately breaks out of the middleware chain. Additionally, the privileged `error` namespace (emitted by `next(err)` and received by the client via `socket.on('error', err)`) is not available for use via the standard `socket.emit('error', err)` on the server. 

For these reasons, the server instead emits all errors to the client via `socket.emit('err', err)`. We use a `./CustomError` Class (inheriting from the native JS Error) to namespace our errors, and then rely on a switch to properly route errors on the client. (This also allows us to track and log outgoing errors via custom middleware on the server.)

Entonces, al pensar en esto nuevamente, si ya incorporó la capacidad de agregar un middleware personalizado a next(err) , ¿también es posible permitir el uso del espacio de nombres socket.emit('error', err) para uso manual en el ¿servidor?

Estoy mirando hacia atrás en ese código y todos mis controladores de eventos se ven así (si es útil verlo):

    socket.on('quotes', async (params) => {
      try {
        await dispatchQuotes(socket, params);
      } catch (err) {
        socket.emit('err', err);
      }
    });

¡Oh! Una cosa más que estoy recordando. Aquí hay una solución alternativa que solía poder monitorear eventos salientes con el propósito de registrar/manejar errores:

  ioServer.on('connection', (socket: Socket) => {
    const emitter = socket.emit;

    // We modify socket.io's native 'emit' method to monitor outgoing
    // events, since socket.use() (middleware) only tracks incoming events.
    socket.emit = (...args: any) => {
      emitter.apply(socket, args);
      outgoingErrorMiddleware(socket, args, app);
    };

etc.

Esta es la forma en que usé el middleware saliente si es útil para ver:

export function outgoingErrorMiddleware(socket: SocketIO$Socket, packet: Packet, app: App) {
  const [eventName, err] = packet;
  const { metrics } = app.locals;
  if (eventName === 'err') {
    logger.error(err);
    metrics.errors += 1;
  }
}

¡Gracias de nuevo por todo su arduo trabajo! Intentaré responder más rápido la próxima vez.

1. Además, dado que el espacio de nombres de 'error' está en la lista negra (el cliente no escuchará socket.emit('error', err) ), no puedo emit un error de algún lugar del servidor que no tiene fácil acceso a next() (es decir, desde dentro de socket.on('event') ). Esto dificulta la creación de una solución uniforme para el manejo de errores.

No estoy seguro de lo que podríamos hacer. ¿Tienes una sugerencia?

@michaelegregious gracias por los ejemplos que proporcionó. (¡y no hay problema por la demora!)

Técnicamente hablando, no estoy seguro de que podamos detectar los errores arrojados por un oyente asíncrono:

socket.on("test", async () => {
  throw new Error("catch me?");
});

try {
  socket.emit("test");
} catch (e) {
  // won't catch the error
}

Así que creo que es mejor dejar que el usuario maneje los errores por sí mismo, ya sea con el código que proporcionó ( socket.emit("err", err); ), o con una función de reconocimiento:

socket.on('quotes', async (params, cb) => {
  try {
    await dispatchQuotes(socket, params);
  } catch (err) {
    cb(err);
  }
});

¿Qué piensas?

Lo que está implementado actualmente para v3:

• "error" pasa a llamarse "connect_error" y está restringido solo al error de middleware de espacio de nombres:

// server
io.use((socket, next) => {
  next(new Error("unauthorized"));
});
// client
socket.on("connect_error", (err) => {
  // err instanceof Error === true
  // err.message === "unauthorized"
})

Lo que también significa que "error" ya no es un nombre de evento reservado.

• socket.use() se elimina y se reemplaza por socket.onAny() (servidor y cliente)

// server
io.on("connect", (socket) => {
  socket.onAny((event, ...args) => {

  });
});

// client
socket.onAny((event, ...args) => {
  // ...
});

¿Te suena bien? ¿Tienes alguna sugerencia?

¡Hola a todos!

enchufe. [email protected] y zócalo. [email protected] están fuera. Puedes probarlos con npm i socket.io<strong i="10">@beta</strong> socket.io-client@beta .

Planeamos lanzar 3.0.0 la próxima semana. Se ha creado la guía de migración: https://socket.io/docs/migrating-from-2-x-to-3-0/ (faltan algunos detalles, como los eventos reservados en el lado del cliente)

Como de costumbre, ¡los comentarios son bienvenidos!

Tengo una duda, no sé si este es el lugar correcto para ello, pero es posible definir la identificación del socket en la conexión, por ejemplo, para usar la identificación del cliente que proviene de la base de datos. ¿Cambiar la propiedad "id" del objeto socket en el middleware de conexión hace que la sincronización con el cliente?

@darrachequesne Gracias por la actualización de RC4.
Con la versión 3.0.0.rc4 - 2 Preguntas:

1. ¿Cuál es la mejor manera de obtener el número o la lista de enchufes (clientes) en una habitación?
2. ¿Cuál es la mejor manera de obtener una lista de todas las salas actuales?

Voy a hacer muchas pruebas en los próximos días con rc4.

Gracias de nuevo por todo su arduo trabajo.

@ferco0 actualmente no es posible, el Socket#id se genera aquí . En su ejemplo (ID de cliente de db), ¿qué sucede si el mismo usuario abre una nueva pestaña? (dado que el Socket#id debe ser único)

@szarkowicz

1. ¿Cuál es la mejor manera de obtener el número o la lista de enchufes (clientes) en una habitación?

io.allSockets() => obtener todos los ID de socket (funciona con varios servidores) (bueno, una vez que se actualiza el adaptador Redis)
io.in("room1").allSockets() => obtener todos los identificadores de socket en la sala

(fue nombrado io.clients() en Socket.IO v2)

1. ¿Cuál es la mejor manera de obtener una lista de todas las salas actuales?

Actualmente no hay una API para eso, además de profundizar en el adaptador: io.of("/").adapter.rooms ( here )

Además, el adaptador Redis tiene un método allRooms , pero no se reflejó en la API pública.

De acuerdo, realmente aprecio la información para obtener clientes y habitaciones tanto con Redis como sin Redis. Probablemente comenzaré a probar solo con socket.io v3 hasta que se actualice el adaptador Redis.

Migrar a webpack 4 (u otro paquete, si es necesario)

Puede echar un vistazo a https://github.com/formium/tsdx como alternativa.
Quería impulsar una reescritura de socket.io & engine.io en Typescript hace algunos meses usando tsdx, aunque no pude encontrar el tiempo para hacerlo :smile:

:rocket: ¡Socket.IO v3.0.0 está disponible! :rocket: Las notas de la versión se pueden encontrar aquí: https://socket.io/blog/socket-io-3-release/

Gracias a todos los involucrados en este hilo por sus ideas/comentarios :heart:

@darrachequesne , todo tiene sentido para mí. Me olvidé de ese tema re. middlewares asíncronos (en mi proyecto actual, hemos creado una función wrap() para que cada ruta Express se ocupe de ese problema exacto, de modo que no se escapen errores).

¡Gracias por todas las mejoras!

¿Te suena bien? ¿Tienes alguna sugerencia?

middleware asíncrono

@michaelegregious , ¿podría abrir una solicitud de función para eso? ¡Gracias!

Cierro este tema ahora. Discusión sobre el lanzamiento: https://github.com/socketio/socket.io/discussions/3674