Socket.io: Дорожная карта для v3

Похоже, отличный план.

Я переключаюсь с nodejs на golang и обнаружил, что нет реализации socket.io 2.
https://github.com/googollee/go-socket.io/issues/188

Что вы думаете о поддержке сервера golang для версии 3? С удовольствием приму участие в этой разработке.

@theromis , вы говорите о клиенте golang (который будет подключаться к серверу Node.js) или о реальном сервере golang? (Я думаю, здесь тоже была проделана некоторая работа: https://github.com/graarh/golang-socketio)

@darrachequesne Спасибо за быстрый ответ, да, я говорю о серверной стороне golang-socketio.
Упомянутый вами проект почти мертв (последний коммит больше года).
https://github.com/googollee/go-socket.io проект ищет сопровождающего.
И ни один из них не поддерживает socket.io v2.
Я подумал, что, может быть, самые лучшие разработчики nodejs socketio также могут быть заинтересованы в разработке golang :)

Обновленный Java-клиент тоже не помешал бы.

Пакет socket.io для серверной стороны Swift, такой как https://github.com/vapor , тоже был бы очень хорош, поскольку клиент Swift уже есть.

Похоже, что если socket.io на стороне сервера будет написан на каком-то родном языке, таком как C/C++, его можно будет использовать везде, включая nodejs, golang, java, rust и так далее...
Что не так с этим подходом?
Мое личное мнение, что socket.io является стандартом де-факто для современного мира. Почему бы не сделать его идеальным?

Одна вещь, которая всегда беспокоила меня в socket.io , которая может быть решена в следующем крупном выпуске, может быть https://github.com/socketio/socket.io/issues/2124 и https://github.com .

Исторически существовала несогласованность в обработке пространств имен и промежуточного программного обеспечения.
Кроме того, client , испускающий событие reconnect , на мой взгляд, имеет больше смысла после того, как он соединяется с namespace , а не просто событие повторного подключения Менеджера... Например. , если есть какая-то ошибка аутентификации в промежуточном программном обеспечении подпространства имен, клиент все равно получит событие повторного подключения, что, как мне кажется, нелогично.

Начиная с версии node 10.5 появился новый Worker Threads, который в настоящее время находится в экспериментальном состоянии, но когда он будет выпущен, я думаю, что это может быть лучший способ использования socket.io вместо использования сервера Redis.

Плюсы:

• меньше зависимости (redis)
• встроенная поддержка многопоточности
• больше контроля

Против:

• будет работать только с той версией nodejs, которая выпускает рабочий поток (10.x || 11). Но с этим можно справиться.

@Два интересно! Это сработает для воркеров на одном хосте, но как насчет нескольких хостов?

@perrin4869 хорошая идея :+1:

Я оставил много идей здесь: #3311 пожалуйста, прочтите :) Эту тему я закрою и продолжу обсуждение здесь.

@MickL , у вас есть время, например, перенести репозиторий socket.io на Typescript?

Боюсь, мои познания в области сетевых технологий и информационной безопасности ограничены. Я полагаюсь на фреймворки высокого уровня, такие как Express или Socket.io.

Насколько я вижу, socket.io уже написан ООП и хорошо задокументирован, поэтому было бы несложно просто портировать его. Моя идея заключалась в том, чтобы сделать проект как можно более модульным, чтобы кому-то вроде меня было легче вносить свой вклад, а клиент был устойчив к древовидным изменениям. Также может быть идея сделать все проще. В любом случае, я недостаточно хорошо разбираюсь в коде, поэтому обе идеи могут не иметь смысла в этом проекте.

@darrachequesne это хороший вопрос. Я буду думать об этом.

Требуется Nodejs 8 и выше, так как более ранние версии в лучшем случае находятся на обслуживании, см. https://nodejs.org/en/about/releases/ , по крайней мере, nodejs 4 следует удалить (я заметил из .travis.yml, что вы поддерживаете Это)

Началась ли работа, связанная с 3.0, в какой-либо ветке/репозитории? Просто проверяю, есть ли место, где можно быть в курсе того, как идут дела или какой вклад они вносят.

Я хотел бы видеть улучшенную поддержку обработки ошибок на стороне сервера. Это было поднято в нескольких других проблемах, но, в частности, было бы здорово, если бы:

1. В дополнение к программному обеспечению по умолчанию была поддержка пользовательского промежуточного программного обеспечения для обработки ошибок. Это может выглядеть примерно как Express (которое может быть добавлено как последнее в цепочке app.use() , аналогично socket.use() , промежуточное программное обеспечение): https://expressjs.com/en/guide/error -handling.html

Проблема в настоящее время заключается в том, что нет возможности добавить какой-либо способ отслеживания или регистрации ошибки после того, как она nexted .

1. Кроме того, поскольку пространство имен 'error' занесено в черный список, socket.emit('error', err) не будет услышано клиентом), я не могу emit получить ошибку где-то на сервере, где нет простого доступ к next() (т.е. изнутри socket.on('event') ). Это затрудняет создание единого решения для обработки ошибок.

2. next(err) должен отправлять объект Error , а не строку. Я понимаю, что для этого есть обходной путь (https://github.com/socketio/socket.io/issues/3371), добавив волшебное свойство .data к любому объекту , который вы называете next() на. Однако это не задокументировано и не интуитивно понятно.

Вообще говоря, next(err) кажется ненужным черным ящиком с очень ограниченными возможностями обработки ошибок.

Спасибо за ваш труд, так держать!

@darrachequesne Какие-нибудь новости о том, что версия 3 стала реальностью? Я не видел никакого прогресса в этом с 2018 года.

Короткое обновление: мой текущий контракт был недавно обновлен, и я должен иметь возможность посвятить один день в неделю (1/5 дня) обслуживанию проекта. Таким образом, работа над v3 должна быть вскоре возобновлена.

Очень хочется помочь этому проекту так или иначе.

Если есть способ определить, как я могу это сделать, дайте мне знать - я просто не хочу потенциально исправлять вещи, чтобы они не были объединены! Так что лучше дождаться какого-то руководства, если нужна помощь. Ваше здоровье

• сжатие (gzip, zlib, defalte/inflate)
• переработан механизм отправки бинарных данных (теперь 2 пакета... ws text и ws binary)
• отправлять метаданные при подключении (использовать сжатие?)
• кодеры/кодировщики в качестве плагинов включают пользовательские (messagepack, protobuf и т. д.), мы могли бы использовать дженерики, если код будет переписан в машинописный текст
• закрепление сертификата (сервер/клиент)

@blackkopcap

сжатие (gzip, zlib, defalte/inflate)

Сжатие уже поддерживается. Сжатие WebSocket ( perMessageDeflate ) будет отключено по умолчанию в версии 3, поскольку для этого требуется много дополнительной памяти.

переработан механизм отправки бинарных данных (теперь 2 пакета... ws text и ws binary)

Полностью согласен. Карта добавлена ​​сюда

отправлять метаданные при подключении (использовать сжатие?)

Я не уверен, что понимаю. Не могли бы вы объяснить вариант использования?

кодеры/кодировщики в качестве плагинов включают пользовательские (messagepack, protobuf и т. д.), мы могли бы использовать дженерики, если код будет переписан в машинописный текст

Вы уже должны иметь возможность предоставить свой собственный парсер, например socket.io-msgpack-parser.

закрепление сертификата (сервер/клиент)

:+1:, добавлено сюда .

@michaeleregious

1. В дополнение к программному обеспечению по умолчанию была поддержка пользовательского промежуточного программного обеспечения для обработки ошибок. Это может выглядеть примерно как Express (которое может быть добавлено как последнее в цепочке app.use() , аналогично socket.use() , промежуточное программное обеспечение): https://expressjs.com/en/guide/error -handling.html

Это было бы действительно здорово. Добавлено здесь

1. Кроме того, поскольку пространство имен 'error' занесено в черный список (клиент не услышит socket.emit('error', err) ), я не могу emit получить ошибку где-то на сервере, где нет простого доступ к next() (т.е. изнутри socket.on('event') ). Это затрудняет создание единого решения для обработки ошибок.

Не уверен, что мы могли бы сделать. У вас есть предложение?

1. next(err) должен отправлять объект Error , а не строку. Я понимаю, что для этого есть обходной путь (https://github.com/socketio/socket.io/issues/3371), добавив волшебное свойство .data к любому объекту , который вы называете next() на. Однако это не задокументировано и не интуитивно понятно.

Полностью согласен :+1: , добавлено сюда

Мы уже выпустили Engine.IO v4, который будет включен в Socket.IO v3. Вы можете найти примечания к выпуску здесь .

Я добавил то, что смог найти в этой теме, в проект здесь , чтобы дать обзор прогресса. Не стесняйтесь комментировать!

Вот что я имел в виду для исправления https://github.com/socketio/socket.io/issues/2124

Теперь клиент будет отправлять пакет CONNECT , когда он хочет получить доступ к пространству имен по умолчанию ( / ) (больше никакого неявного соединения).

Это означает, что промежуточное программное обеспечение, зарегистрированное для пространства имен по умолчанию, больше не будет применяться к клиентам, которые хотят получить доступ к пространству имен, отличному от пространства имен по умолчанию.

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

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

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

На стороне клиента, я думаю, мы также должны проводить четкое различие между опцией query для менеджера (которая включена в параметры запроса) и опцией query для сокета (которая отправляется в пакете CONNECT ).

Прямо сейчас:

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

приводит к запросам типа GET /socket.io/?transport=polling&abc=def , а также к пакету CONNECT типа { "type": 0, "nsp": "admin?abc=def"}

Кроме того, поскольку для пространства имен по умолчанию нет пакета CONNECT , query сокета в этом случае в настоящее время игнорируется.

Вместо этого я предлагаю переименовать его в authQuery .

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

приведет к запросам типа GET /socket.io/?transport=polling&abc=def и пакету CONNECT типа { "type": 0, "nsp": "/", "data": { abc: '123' } }

@ perrin4869 это имеет смысл?

Изменить: что касается компромиссов, при запуске будет больше HTTP-запросов...

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

Пока у нас на данный момент:

// 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 Спасибо, что приняли это во внимание! Приятно получить здесь некоторое закрытие, наконец-то упростив код, который у меня был тогда: D
Это было давно, поэтому я точно не помню, но это похоже на решение, к которому я стремился.
Из любопытства, в чем причина компромиссов?

Следуя идее о том, как работают формы js: https://web.archive.org/web/20200201163000/https://mathiasbynens.be/notes/shapes-ics . Не лучше ли для повышения производительности использовать массивы для хранения ссылок на соединения сокетов? Все больше и больше соединений, бесчисленные идентификаторы и использование объектов для этого с каждым новым соединением, генерируется новая форма и потребляется больше памяти, в зависимости от времени жизни узла и количества соединений, которые он может иметь, это, вероятно, будет иметь некоторое негативное влияние на производительность.

@ perrin4869 perrin4869 компромиссы связаны с текущей реализацией, поскольку мы сначала устанавливаем соединение Engine.IO, а затем переходим к соединению Socket.IO. Что дает, если транспорт с длительным опросом HTTP включен (по умолчанию):

• запрос HTTP GET для получения рукопожатия Engine.IO
• запрос HTTP POST для отправки пакета Socket.IO CONNECT
• запрос HTTP GET для получения пакета Socket.IO CONNECT с сервера
• а затем обновление до WebSocket

Но его, безусловно, можно было бы улучшить. Для справки, изменение реализовано здесь и здесь .

Кроме того, событие reconnect больше не будет генерироваться экземпляром Socket (на стороне клиента) ( здесь ).

@ferco0 теперь мы будем использовать Map вместо простого объекта (https://github.com/socketio/socket.io/commit/84437dc2a682add44bb57d03f703cfc955607352). В таком случае ваш комментарий все еще актуален?

[email protected] и [email protected] были опубликованы :fire:

Несколько заметок:

• общедоступный API не сильно изменился (хотя несколько методов были удалены, см. здесь и здесь для справки)
• кодовая база была перенесена на TypeScript, но некоторые типизации отсутствуют, особенно на стороне клиента.
• включены критические изменения в Engine.IO v4 (перечислены здесь ).
• размер пакета клиента немного увеличился, несмотря на меньшее количество зависимостей, я покопаюсь в этом

Любая обратная связь приветствуется!

@darrachequesne все в порядке.

@darrachequesne Многие проекты с открытым исходным кодом npm пытаются уменьшить количество зависимостей. Это своего рода тенденция в обществе. Основная причина в том, что многие организации требуют проверки лицензий всех используемых зависимостей при их использовании в проектах, чтобы не столкнуться с юридическими проблемами. Конечно, в этом помогает меньшее количество зависимостей. Например, Helmet (отличный пакет безопасности для веб-сервера Express) перешел к установке с нулевой зависимостью в последней версии 4.0.

Имея это в виду, есть ли план уменьшить количество зависимостей в socket.io в выпуске 3?

@thernstig , это хороший вопрос! Мы действительно пытались уменьшить количество зависимостей в 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

Вот дерево зависимостей для сервера:

[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

Я думаю, что нам нужна только папка socket.io-client dist/ socket.io-client, поэтому может иметь смысл создать socket.io-client-dist без зависимостей. Как вы думаете?

Примечание: розетка. [email protected] и сокет. [email protected] были опубликованы

Я добавил несколько примеров с модулями ES и TypeScript .

@darrachequesne Я оставляю это на ваше усмотрение 😄

@michaeleregious относительно вашего комментария , я знаю, что прошло довольно много времени, но вы имели в виду конкретный API?

Я согласен с тем, что текущий API можно улучшить. Он был реализован как способ иметь универсальный слушатель (обсуждается здесь ), а не для обработки ошибок.

Мы также можем добавить способ предупреждения пользователей о необработанных событиях (ответы 404 в Express, http://expressjs.com/en/starter/faq.html#how-do-i-handle-404-responses).

@darrachequesne приятно слышать, что вы работаете над следующей версией socket.io !! Заранее спасибо за всю вашу работу над этой библиотекой.

В настоящее время я тестирую socket. [email protected] и сокет. [email protected], и я пытаюсь использовать новый синтаксис для присоединения к комнате и передачи в сокеты в этой комнате.

Я не могу заставить сервер излучать в клиентский сокет, используя ваш пример в файле журнала изменений.

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

Прикреплены скриншоты, показывающие файл сокета js, используемый на клиенте, и код для сервера node.js.

js-файл на стороне клиента

Событие socket.on на стороне клиента

Синтаксис соединения на стороне сервера внутри io.on("connect",

Я перепробовал все методы на последнем снимке экрана, чтобы заставить его передать клиенту, и ничего не работает.

Пожалуйста, дайте мне знать, если вам нужна дополнительная информация.

Спасибо

@darrachequesne Я понизил версию до 3.0.0-rc2 и присоединился к комнате, используя метод обратного вызова «room1», который срабатывает, но ни одно из событий отправки не отправляется клиенту.

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

Я также удалил 3.0.0-rc2 и установил socket.io 2.3.0 для сервера и клиента и подтвердил, что приведенный выше код работает должным образом. Так что я считаю, что что-то сломалось с версиями 3.0.0 rc

@szarkowicz Хм... Я не могу воспроизвести поведение, которое вы описываете: https://github.com/socketio/socket.io-fiddle/tree/issue/v3

Следующий код работает, как и ожидалось:

socket.join("room1");

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

Вы получаете какую-либо ошибку в консоли? Получаете ли вы событие connect на стороне клиента?

@darrachequesne спасибо за подтверждение. Я проследил это до использования redisAdapter, вызывающего проблему. Как только я закомментирую следующий код, rc3-версия socket.io заработает, как и ожидалось.

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

Вы пытались использовать Redis с v3 socket.io?

Спасибо

@szarkowicz да, вы абсолютно правы, адаптер Redis необходимо обновить, чтобы он соответствовал Socket.IO v3, он будет обновлен сразу после выпуска 3.0.0 (который должен быть скоро).

В любом случае большое спасибо за отзыв :+1:

@darrachequesne хорошо звучит!!! Я пока просто не буду его использовать и продолжу тестировать без него.

Есть ли у вас время, когда вы думаете, что v3 будет выпущена?

Не беспокойтесь - еще раз спасибо, что ответили мне и работали над всеми улучшениями для следующей версии!

@darrachequesne Большое спасибо за эти обновления! Извините за мой запоздалый ответ! Мы не используем socket.io в моем текущем проекте (хотя мы можем интегрировать его в будущем), но обходной путь, который я использовал в своем последнем проекте, заключался в использовании socket.emit('err', err) вместо использования привилегированного пространства имен. socket.emit('error', err) .

Вот примечание, которое я поместил в файл readme нашего приложения, чтобы объяснить проблему:

#### 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.)

Итак, если подумать еще раз, если вы уже включили возможность добавления пользовательского промежуточного программного обеспечения в next(err) , возможно ли также разрешить использование пространства имен socket.emit('error', err) для ручного использования на сервер?

Я оглядываюсь назад на этот код, и все мои обработчики событий выглядят так (если это полезно видеть):

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

Ой! Еще одна вещь, которую я помню. Вот обходной путь, с помощью которого я мог отслеживать исходящие события с целью ведения журнала/обработки ошибок:

  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.

Вот как я использовал исходящее промежуточное ПО, если это будет полезно:

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

Еще раз спасибо за всю вашу тяжелую работу! В следующий раз постараюсь быстрее ответить.

1. Кроме того, поскольку пространство имен 'error' занесено в черный список (клиент не услышит socket.emit('error', err) ), я не могу emit получить ошибку где-то на сервере, где нет простого доступ к next() (т.е. изнутри socket.on('event') ). Это затрудняет создание единого решения для обработки ошибок.

Не уверен, что мы могли бы сделать. У вас есть предложение?

@michaeleregious спасибо за примеры, которые вы предоставили. (и никаких проблем с задержкой!)

С технической точки зрения, я не уверен, что мы сможем отловить ошибки, выдаваемые асинхронным слушателем:

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

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

Поэтому я думаю, что лучше позволить пользователю обрабатывать ошибки самостоятельно либо с помощью предоставленного вами кода ( socket.emit("err", err); ), либо с помощью функции подтверждения:

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

Как вы думаете?

Что на данный момент реализовано для v3:

• «Ошибка» переименована в «connect_error» и ограничена только ошибкой промежуточного программного обеспечения пространства имен:

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

Это также означает, что «ошибка» больше не является зарезервированным именем события.

• socket.use() удален и заменен на socket.onAny() (сервер и клиент)

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

  });
});

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

Это звучит хорошо для вас? Есть ли у вас предложения?

Всем привет!

разъем. [email protected] и сокет. [email protected] отсутствует. Вы можете проверить их с помощью npm i socket.io<strong i="10">@beta</strong> socket.io-client@beta .

Мы планируем выпустить 3.0.0 на следующей неделе. Создано руководство по миграции: https://socket.io/docs/migrating-from-2-x-to-3-0/ (некоторые детали отсутствуют, например зарезервированные события на стороне клиента)

Как обычно, отзывы приветствуются!

У меня есть сомнения, я не знаю, правильное ли это место для этого, но можно ли определить идентификатор сокета при подключении, например, чтобы использовать идентификатор клиента из базы данных? Изменение реквизита «id» объекта сокета в промежуточном программном обеспечении соединения делает синхронизацию с клиентом?

@darrachequesne Спасибо за обновление RC4.
С версии 3.0.0.rc4 - 2 вопроса:

1. Как лучше всего получить количество или список сокетов (клиентов) в комнате?
2. Как лучше всего получить список всех текущих комнат?

В ближайшие несколько дней мы проведем много тестов с rc4.

Еще раз спасибо за всю вашу тяжелую работу.

@ferco0 в настоящее время это невозможно, здесь создается Socket#id. В вашем примере (идентификатор клиента из базы данных), что произойдет, если тот же пользователь откроет новую вкладку? (поскольку Socket#id должен быть уникальным)

@szarkowicz

1. Как лучше всего получить количество или список сокетов (клиентов) в комнате?

io.allSockets() => получить все идентификаторы сокетов (работает с несколькими серверами) (ну, после обновления адаптера Redis)
io.in("room1").allSockets() => получить идентификаторы всех сокетов в комнате

(он назывался io.clients() в Socket.IO v2)

1. Как лучше всего получить список всех текущих комнат?

В настоящее время для этого нет API, кроме как копаться в адаптере: io.of("/").adapter.rooms ( здесь )

Кроме того, у адаптера Redis есть метод allRooms , но он не нашел отражения в публичном API.

Хорошо, очень ценю информацию, чтобы получить клиентов и комнаты как для Redis, так и для Non Redis. Я, вероятно, начну тестирование только с socket.io v3, пока адаптер Redis не будет обновлен.

Перейдите на webpack 4 (или другой упаковщик, если это необходимо)

В качестве альтернативы вы можете взглянуть на https://github.com/formium/tsdx .
Несколько месяцев назад я хотел переписать socket.io и engine.io в Typescript с помощью tsdx, но не смог найти на это времени :smile:

:rocket: Вышел Socket.IO v3.0.0! :rocket: Примечания к выпуску можно найти здесь: https://socket.io/blog/socket-io-3-release/

Спасибо всем участникам этой темы за ваши идеи/отзывы :heart:

@darrachequesne , для меня все это имеет смысл. Я забыл об этой проблеме. асинхронное промежуточное ПО (в моем текущем проекте мы создали функцию wrap() для каждого экспресс-маршрута, чтобы решать именно эту проблему, чтобы никакие ошибки не просачивались сквозь трещины).

Спасибо за все улучшения!

Это звучит хорошо для вас? Есть ли у вас предложения?

асинхронное промежуточное ПО

@michaeleregious , не могли бы вы открыть запрос на эту функцию? Спасибо!

Я сейчас закрою этот вопрос. Обсуждение релиза: https://github.com/socketio/socket.io/discussions/3674