Насколько часто по вебсокет могут не доходить меседжи до цели?

Question

[Онотолий]

Здравствуйте уважаемые знатоки.
Я разрабатываю вебсокет приложение в котором каждый меседж прилетевший с сервера или улетевший к серверу очень важен, т.е. чтобы доходил до своей цели.
Тоесть вот мы установили соединение по вебсокет и начинаем гонять по нему меседжи в json формате, меседжи короткие, не большие, максимальная скорость 1 рас в секунду ну или чуть чаще.

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

Comments

[Василий Банников]

А на сколько реально важна доставка сообщения? Что случится, если клиент не получит его?

[Онотолий]

Василий Банников, Будет плохо, некорректно работающий проект

[Василий Банников]

Онотолий, А что за сообщения вообще и кто является клиентом и сервером? На сколько стабильное соединение? Какая задержка допустима?
Может можно другой транспорт использовать?

Answer 1

[VoidVolker]

На столько, на сколько часто этом может происходить в любом TCP соединении.
https://ru.wikipedia.org/wiki/TCP

Хотя протокол осуществляет проверку контрольной суммы по каждому сегменту, используемый алгоритм считается слабым [1]. В общем случае распределенным сетевым приложениям рекомендуется использовать дополнительные программные средства для гарантирования целостности передаваемой информации[2].

Т.о. в вашем случае вам следует дополнительно реализовать свой механизм контроля доставки сообщений в рамках используемого вами протокола поверх WS или поверх самого протокола. Так же имеет смысл использовать пульс - периодический пинг клиента/сервера. Например, в случае плохой мобильной связи соединение может оборваться, но и клиент и сервер будут считать, что оно есть и пытаться отправить или ожидать данные. При этом, теоретически и согласно всем нормам уже на уровне ОС сокет должен закрыться через несколько секунд, но тут вступает в дело такой фактор как "опции создания сокета" и, особенно, "таймаут сокета" - разные разработчики могут использовать разные опции при запуске сервера/клиента и как результат в разных ОС это поведение может отличаться и сокет может зависнуть, а ОС его сама не закроет. Так что тут поможет только пульс - в WS пинг часть протокола.

Comments

[Онотолий]

Да, скорее всего придется делать на прикладном уровне некий syn/ack. А на счет пингов то они так идут у меня, это я сделал

[VoidVolker]

Онотолий,

на счет пингов то они так идут у меня, это я сделал

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

Answer 2

[Everything_is_bad]

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

ЗЫ если чё, именно так и делают при "очень важен".

Answer 3

[Василий Банников]

Вебсокеты сделаны поверх TCP, так что пока соединение работает - сообщения все должны доходить.
Но соединение может какое-то время оставаться номинально живым после фактического разрыва, так что для контроля живости стоит через одинаковые промежутки отправлять какие-нибудь пинги / keep alive сообщения.
Тогда как только они прекратятся - можно будет сразу понять, что кто-то отвалился.

Для гарантий доставки можно ещё продублировать вебсокеты каким-нибудь rpc, типа если произошёл разрыв - клиент синхронно запрашивает события, которые мог пропустить.