Socket.io: Постоянная «транспортная близость» к клиенту

Любые новости по этой проблеме, потому что у меня точно такая же проблема!

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

Я тоже страдаю от этого ...

@ talas9 @muhammadnasr @htamop общие вопросы, чтобы иметь возможность отлаживать / воспроизводить проблему:

• какую версию клиента / сервера вы используете?
• какой браузер?
• воспроизводится ли это на скрипке ?

Спасибо!

Я пробовал это с клиентом и сервером 2.1.0 и 2.0.4. На хроме и сафари (последняя версия).
Когда я запускаю локально, он работает нормально (можно подключать более часа без отключения), но когда я развертываю K8ns за входным балансировщиком нагрузки, эта проблема возникает ...

К вашему сведению, соединение закрывается ровно через 25 секунд каждый раз, см. Снимок экрана

@ talas9 @htamop @ dnwldbs84 вы используете балансировщик нагрузки?

@darrachequesne Какие балансировщики нагрузки вы рекомендуете использовать с socket.io?

@muhammadnasr @darrachequesne
Я использовал сервер 2.1.0 и клиент 1.0.0 (android)
Мне нужно поддерживать стабильное соединение в течение 8–9 часов, но оно неожиданно отключается.
Поменял обе версии на 1.7.4 и 0.8.3? согласно другому сообщению решения. Я попробую завтра проверить, работает ли он хорошо

Я не использовал балансировщик нагрузки. И клиент, и сервер использовали версию Socket.io 2.0.3 (я не могу вспомнить все версии, которые я использовал). Я не знаю, какой браузер вызывает проблему. Однако большинство пользователей использовали Chrome. В моем случае отключение было случайным, поэтому его невозможно воспроизвести.
И я перешел на ws. Я не уверен, что проблема решена.

@muhammadnasr @darrachequesne @ dnwldbs84
Думаю, в моем случае это решено.
Я использую 0.8.3 socket.io-client в службе переднего плана Android (api 26) и версию 1.3.5 на сервере nodejs.
Однако проблема может быть не в версии.
Я изменил pingInterval на сервере на 10 мс, и, похоже, он работает правильно (тайм-аут ping и закрытие транспорта не произошло)
var io = require ('socket.io') (http, {pingInterval: 10, pingTimeout: 4000});

10 миллисекунд - это слишком мало, поэтому сеть будет перегружена.

10 миллисекунд - это сужение, тогда сеть будет перегружена.

Верный!

@muhammadnasr любой балансировщик нагрузки должен работать. См. Следующие примеры:

• https://github.com/socketio/socket.io/tree/master/examples/cluster-haproxy
• https://github.com/socketio/socket.io/tree/master/examples/cluster-nginx
• https://github.com/socketio/socket.io/tree/master/examples/cluster-httpd

Однако липкий сеанс необходим, если вы включили опрос (по умолчанию).

@darrachequesne У меня такая же проблема, примерно через 8 ~ 9 часов сокет отключается по причине "транспортного закрытия"

Я использую:

Chrome: 61.0.3163.100
Electron: 2.0.2
Socket.io: 2.1.1

Имел ту же проблему, смог исправить ее с помощью CDN из этого комментария https://github.com/socketio/socket.io/issues/3025#issuecomment -329024833 и установив тайм-аут и интервал, как показано ниже:

io.set('heartbeat timeout', 60000);
io.set('heartbeat interval', 25000);

Привет,
У нас такая же проблема с socket.io, когда он работает под Kubernetes и NGINX Ingress Controller.
Когда конфигурация nginx перезагружается, он воссоздает процесс, и все существующие коммуникации отбрасываются, что вызвало transport close , любые другие развертывания, использующие входной контроллер, могут вызвать перезагрузку конфигурации.

Прежде всего, большое спасибо за этот потрясающий проект.

Та же проблема, может, я принесу тебе что-нибудь новенькое.

У меня есть сервер WS и клиент WS на узле js.
Этот клиент ws используется из приложения node js, где находится служба (микросервис).

Другие клиенты ws из веб-браузеров (из клиентских приложений) обмениваются данными через сервер ws с этой службой js узла.

Все работает как положено.

На стресс-тестах сейчас (10 клиентов интенсивно запрашивают данные), по окончании тестов, когда все задания и транзакции завершены, соединение сервиса закрывается с ошибкой «закрытие транспорта». Так бывает не всегда.

Это конфиг сервера:
pingTimeout: 15000,
pingInterval: 20000,
Похоже, что при большой нагрузке пропадают какие-то пинги ...? или я не знаю.
Это то, чего я должен ожидать?

Кроме того, с конфигурацией по умолчанию pingTimeout: 2000 я получал эту ошибку в середине стресс-теста. Это тоже было совершенно неожиданно, но предположим, что сервер был перегружен и не мог ответить в течение 2 секунд (!), И мы могли бы получить эту ошибку. А вот с pingTimeout: 15000 бывает почти на 50% и только после окончания тестов.

Хмхо, я считаю, что микросервисы должны ожидать такого рода ошибок, даже если они работают на одной и той же локальной сети, но вопрос в том, почему это происходит?

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

Как активировать логи? DEBUG = socket.io * не работает. Хотя переменная установлена, я не получаю никаких результатов.

Я твердо уверен, что это связано с № 2924.
Повторное подключение на клиенте вызвано тем, что некоторые браузеры (Safari и Chrome) регулируют таймеры для неактивных вкладок для экономии заряда батареи.
Это приводит к отложенным контрольным сообщениям от клиента и сервера, закрывающего соединение из-за pingTimeout.
Увеличение pingTimeout в некоторой степени работает, но я все еще получаю переподключения в производственной среде.

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

@muhammadnasr, где вы можете решить проблему с развертыванием на K8s? У меня похожие проблемы.

@ bheema01 просто убедитесь, что у вас включена липкая сессия на вашем прокси / балансировщике нагрузки, и она должна работать

Получил такую ​​же ошибку

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

Я видел эту ошибку, когда поток часто блокировался более 200 мс.
Если это происходит часто, это плохо для socket.io _ и вашего приложения также_.
У socket.io есть тайм-аут для проверки пульса соединения.
Если этот таймаут превышен, соединение отключается, и мы получаем эту ошибку.

@varunSabnis после исправления липкой сессии все

@dennisat Я попытался проверить, сколько времени потребовалось моему клиенту, чтобы получить пакет с понгом. Каждый раз он превышал 200 мс, что было проверено как с сервером сокетов в облаке, так и с сервером сокетов на моем локальном хосте. Локальная настройка не отключает сокет (все работает нормально), тогда как в облачной настройке сокет постоянно подключается и отключается. Так что я не думаю, что это проблема.
@muhammadnasr хорошо, это здорово. Фактически включили его, но все еще есть некоторые проблемы.

@muhammadnasr @darrachequesne @ dnwldbs84
Думаю, в моем случае это решено.
Я использую 0.8.3 socket.io-client в службе переднего плана Android (api 26) и версию 1.3.5 на сервере nodejs.
Однако проблема может быть не в версии.
Я изменил pingInterval на сервере на 10 мс, и, похоже, он работает правильно (тайм-аут ping и закрытие транспорта не произошло)
var io = require ('socket.io') (http, {pingInterval: 10, pingTimeout: 4000});

Работает волшебно, спасибо !!!!!!!

Я обнаружил, что транспорт закрывается каждый интервал проверки связи.

Я действительно устал от этой проблемы.
Я думаю, вам стоит проверить версию socket.io с помощью socket.io-client.
если версия сервера / клиента не совпадает, соединение было очень нестабильным.

Я рекомендую просто использовать CDN для клиента, как показано ниже.