WebSocket
От: Videoman Россия https://hts.tv/
Дата: 27.02.20 14:13
Оценка:
На днях обнаружил (для себя) интересную особенность WebSocket-та: onmessage обработчики срабатывают в порядке отличном от порядка send на отправляющей стороне. Казалось бы, web и это вполне может быть в асинхронной среде, но хотелось бы внятного описания в документации, может кто-то встречал??? Самому найти не получилось
Re: WebSocket
От: Mystic Artifact  
Дата: 27.02.20 14:18
Оценка: +2
Здравствуйте, Videoman, Вы писали:

Это вроде не нормальное поведение. Кто является отправителем сообщений? Может быть серверный фреймворк не даёт таких гарантий?
Re: WebSocket
От: Pzz Россия https://github.com/alexpevzner
Дата: 27.02.20 17:30
Оценка:
Здравствуйте, Videoman, Вы писали:

V>На днях обнаружил (для себя) интересную особенность WebSocket-та: onmessage обработчики срабатывают в порядке отличном от порядка send на отправляющей стороне. Казалось бы, web и это вполне может быть в асинхронной среде, но хотелось бы внятного описания в документации, может кто-то встречал??? Самому найти не получилось


Если это один вебсокет, такого быть не должно. Если два вебсокета, хоть бы и в одно и то же место, такое запросто может быть.
Re[2]: WebSocket
От: Videoman Россия https://hts.tv/
Дата: 28.02.20 09:11
Оценка:
#Имя: {40A3ADF4-F222-404F-9EAD-E17F7142143E}
Здравствуйте, Mystic Artifact, Вы писали:

MA>Это вроде не нормальное поведение. Кто является отправителем сообщений? Может быть серверный фреймворк не даёт таких гарантий?


Все происходит в локальной сети. Отправляются пакеты со стороны браузера. На сервере (простейший С++, TCP сокет, свой маленький парсер WebSocket пакетов) они принимаются в точно таком же порядке как и отправлялись. Здесь все как и ожидалось никогда никаких переупорядочиваний нет. Пакеты это простейший json в котором присутствует номер пакета и этот номер отправляется обратно вместе с ответом. С++ сервер работает на одном сокете строго последовательно (принял-отдал, принял-отдал).
На приеме в браузере в обработчиках onmessage детектируется номера ответов. В спокойных условиях порядок также не меняется, а вот если нагрузить сеть близко к 100%, то номера ответов в обратных вызовах onmessage иногда начинают перемешиваться — меняется порядок.
P.S. Браузер Chrome 80.0.3987.116
Re[2]: WebSocket
От: Videoman Россия https://hts.tv/
Дата: 28.02.20 10:07
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Если это один вебсокет, такого быть не должно. Если два вебсокета, хоть бы и в одно и то же место, такое запросто может быть.


Естественно один, иначе бы и вопросов не было. Я в соседней ветке постарался описать подробнее условия WebSocket теста.
Re[3]: WebSocket
От: Mystic Artifact  
Дата: 28.02.20 10:26
Оценка:
Здравствуйте, Videoman, Вы писали:

V>P.S. Браузер Chrome 80.0.3987.116

Попробуй FF. Если всё вышеописанное — правда, то это больше похоже на баг, хотя у них такие жидкие спецификации, что даже если предъявишь — то наверняка найдут оправдание.
Re[4]: WebSocket
От: Videoman Россия https://hts.tv/
Дата: 28.02.20 11:49
Оценка:
Здравствуйте, Mystic Artifact, Вы писали:

MA> Попробуй FF. Если всё вышеописанное — правда, то это больше похоже на баг, хотя у них такие жидкие спецификации, что даже если предъявишь — то наверняка найдут оправдание.


Можно конечно, но FF умирающий браузер и он слишком мало распространен что бы я мог игнорировать Chrome. Пока по экспериментам получается так: если работаем в "расслабленном" режиме, то все ок. Если нагружаем WebSocket на приеме и JS код не успевает растаскивать пакеты, то внутренняя очередь которая дергает onmessage, как-то умудряется менять порядок вызовов. Сразу в onmessage callback стоит логирование, поэтому другую асинхронность я исключаю. Еще что заметил, что порядок меняется как у стека, типа: отправили 1,2,3,4,5,6...
приняли: 3,2,1,4,6,5....
Re[5]: WebSocket
От: Mystic Artifact  
Дата: 28.02.20 12:48
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Можно конечно, но FF умирающий браузер и он слишком мало распространен что бы я мог игнорировать Chrome.

Цель не в том, что бы определить кто из них лучше, а в том, что бы выявить является ли обнаруженное поведение общим. Хотя, рискну предположить, то FF окажется слишком старомодным то бы наступить на эти грабли.

V>Пока по экспериментам получается так: если работаем в "расслабленном" режиме, то все ок. Если нагружаем WebSocket на приеме и JS код не успевает растаскивать пакеты, то внутренняя очередь которая дергает onmessage, как-то умудряется менять порядок вызовов. Сразу в onmessage callback стоит логирование, поэтому другую асинхронность я исключаю. Еще что заметил, что порядок меняется как у стека, типа: отправили 1,2,3,4,5,6...

V>приняли: 3,2,1,4,6,5....
В спеке говорится, что message должен становится в очередь задач (tasks), и что только microtasks в некоторых случаях могут переехать в другую очередь. Но очередь на то и очередь, что она упорядочена. Однако в реальной реализации спеки деталей много больше, так например я вполне допускаю (когда-то по крайней мере такое наблюдал), что внутренние меж-процессные сообщения вполне могут доставляться вне своего порядка. Но, это опять таки не про все сообщения, так что тут я не имею никакой информации конкретно на твой случай.
Если данный эффект действительно имеет место быть, то он должен быть вполне легко наблюдаем/повторяемым на одной машине через локалхост, иначе это больше похоже на какие-то странности сети (что тоже звучит дико).
Собственно дальше нужен только код повторения и либо пробовать повторять, репортить ошибку (или получить внятный ответ что это не ошибка), либо искать ошибку в своём коде, либо ещё где...

PS: Я согласен, что вопрос как-то не особо освящен, то ли я тоже слепой. Но код хрома колупать не буду, если не увижу такое поведение сам.
Re: WebSocket
От: reversecode google
Дата: 28.02.20 13:00
Оценка:
уверенны что со стороны сервера они уходят в правильном порядке ?
а если заллогировать + tcpdump навесить ?

вебсокеты в хроме используются везде и по всюду
если бы были такие проблемы их бы уже выявили

помнится недавно была тема по переупорядовачивание tcp пакетов
вы случайно не соседи с тем ТС ? ))
Re[2]: WebSocket
От: Videoman Россия https://hts.tv/
Дата: 28.02.20 14:14
Оценка:
Здравствуйте, reversecode, Вы писали:

R>уверенны что со стороны сервера они уходят в правильном порядке ?


100%. На передающей и принимающей стороне все залогировано. Более того, в нашем протоколе в пакеты специально были заложены порядковые номера для проверки случайного нарушения логики в нашем коде. Код у кучи клиентов работает уже несколько лет. Но вот у одного из клиентов в ситуации загрузки сети стали вылетать ассерты, так я и узнал о проблеме и теперь пытаюсь выяснить причину, и не в коем случае не утверждаю что в нашем коде нет какой-то хитрой ошибки (если есть, то 100% в части JS).

R>вебсокеты в хроме используются везде и по всюду

R>если бы были такие проблемы их бы уже выявили

Ну я не знаю. Зачем тогда он сделан message-ориентиованным? Если в протоколе никак не полагаться на порядок сообщений, то можно и не заметить, там же все асинхронно. Полагаться на порядок в вебе даже вредно. Там же кругом асинхронщина и если, например, пакеты пришли 1,2,3 и мы их передали асинхронно на обработку, то обработка пакетов запросто может закончится как 3,2,1.
В RFC я нашел единственно упоминание что сообщение может быть фрагментировано и фрагменты ДОЛЖНЫ быть получены принимающей стороной строго в порядке отправки, но я не понял какие фрагменты они имеют ввиду, сами сообщения или фрагменты сообщений.

R>помнится недавно была тема по переупорядовачивание tcp пакетов

R>вы случайно не соседи с тем ТС ? ))
нет
Re[6]: WebSocket
От: Videoman Россия https://hts.tv/
Дата: 28.02.20 14:18
Оценка:
Здравствуйте, Mystic Artifact, Вы писали:

MA> PS: Я согласен, что вопрос как-то не особо освящен, то ли я тоже слепой. Но код хрома колупать не буду, если не увижу такое поведение сам.


Я не могу сейчас сказать 100% где ошибка. Поэтому и спрашиваю у коллег. Может быть кто-то может ткнуть в спецификацию где явно написано что такого быть не может, или наоборорот, скажет что сталкивался с таким поведением, или знает в чем может быть дело. Пока продолжаю рассматривать все выдвинутые версии почему так может быть.
Re[3]: WebSocket
От: reversecode google
Дата: 28.02.20 14:32
Оценка:
пусть клиент заллогирует tcp сессию на своей стороне
и проверите в варешарке что там
99% это глюкавое оборудование в его сети

поверх websocket строятся и чаты и видео сессии
если бы порядок мог нарушаться — это бы не работало
Re[4]: WebSocket
От: Videoman Россия https://hts.tv/
Дата: 28.02.20 15:13
Оценка:
Здравствуйте, reversecode, Вы писали:

R>пусть клиент заллогирует tcp сессию на своей стороне

R>и проверите в варешарке что там
R>99% это глюкавое оборудование в его сети
Сам TCP ничего не переупорядочивает, никогда. Не вижу смысла это рассматривать серьезно.

R>поверх websocket строятся и чаты и видео сессии

R>если бы порядок мог нарушаться — это бы не работало
Вы не поверите, но я именно этим сейчас и занимаюсь, делаю чаты и видео сессии в Web, и я никак не пойму зачем мне закладываться на порядок прихода сообщений по WebSocket-у ??? У каждого сообщения всегда есть метка времени и по ней принимающая сторона все упорядочивает. Я просто пытаюсь точно понять поведение веб сокета (не сокета TCP), что бы избежать проблем в будущем. Так-то можно прямо сейчас пятью строчками сделать очередь и руками упорядочить все запросы. Хочется понять причину и понять как правильно, а заодно исключить причину ошибки где-то еще.

Что-то мы уходим в совсем сторону...
Re[5]: WebSocket
От: reversecode google
Дата: 28.02.20 15:28
Оценка:
V>Сам TCP ничего не переупорядочивает, никогда. Не вижу смысла это рассматривать серьезно.

при этом вы серьезно рассматриваете переупорядовачивание в websocket

мне лениво за вас было гуглить
но ок
вбиваем в гугл
WebSocket onmessage out of order
и читаем ответы
https://stackoverflow.com/questions/11804721/can-websocket-messages-arrive-out-of-order
https://stackoverflow.com/questions/14287224/processing-websockets-messages-in-order-of-receiving
Re[7]: WebSocket
От: Mystic Artifact  
Дата: 28.02.20 20:45
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Я не могу сейчас сказать 100% где ошибка. Поэтому и спрашиваю у коллег. Может быть кто-то может ткнуть в спецификацию где явно написано что такого быть не может, или наоборорот, скажет что сталкивался с таким поведением, или знает в чем может быть дело. Пока продолжаю рассматривать все выдвинутые версии почему так может быть.


Тут в соседней ветке безаппеляционно говорят, что это может быть сеть. Я лично своими глазами видел как работает глючащая сеть, поэтому тоже вполне верю в такое, хотя это и редко (на мой взгляд).
Ты ж сам сказал, что для спец эффектов надо нагрузить сеть. Про нагрузку проца или сопутствующего IO ты умолчал — только гадать. Если это повторимо только на железе клиента... но неповторимо на локальном железе с настоящей сетью, со свичом или без него — то я бы все таки смотрел в сторону сети и/или драйверов.
С той же стороны — вебсокеты можно и по http2 толкать и есть даже мультепликсирование. В хроме фактически есть 3 транспорта для них. Плюс довольно запутанный путь в браузере окромя этого.
Я бы не стал полагаться на то, что в хроме там всё на вебсокетах и все работает — там ничего на вебсокетах нету, кроме девтулз, транспорт к которому обеспечивается обычно не тцп, а парой обычных вызовов и весь протокол полностью асинхронный и на порядок не полагается. Да его там и не может быть — события о которых он говорит из другого процесса и синхронно не обрабатываются.

UPD: Имел ввиду, что так как я видел это изнутри — я знаю что это за халабуда и слепо бы не верил в идеальность браузера. Но вместе с тем, мне лично, кажется объяснение с сетью более вероятным.
Отредактировано 28.02.2020 20:48 Mystic Artifact . Предыдущая версия .
Re: WebSocket
От: Aquilaware  
Дата: 29.02.20 06:23
Оценка:
Здравствуйте, Videoman, Вы писали:

V>На днях обнаружил (для себя) интересную особенность WebSocket-та: onmessage обработчики срабатывают в порядке отличном от порядка send на отправляющей стороне.


Посмею предположить, что ваш сервер неосознанно делает send из нескольких потоков в один сокет, Unix такое позволяет. В результате получаем race condition и "переупорядочивание" сообщений на принимающей стороне.
Re[3]: WebSocket
От: Michael  
Дата: 29.02.20 11:46
Оценка: 11 (2)
Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, Mystic Artifact, Вы писали:


MA>>Это вроде не нормальное поведение. Кто является отправителем сообщений? Может быть серверный фреймворк не даёт таких гарантий?


V>Все происходит в локальной сети. Отправляются пакеты со стороны браузера. На сервере (простейший С++, TCP сокет, свой маленький парсер WebSocket пакетов) они принимаются в точно таком же порядке как и отправлялись. Здесь все как и ожидалось никогда никаких переупорядочиваний нет. Пакеты это простейший json в котором присутствует номер пакета и этот номер отправляется обратно вместе с ответом. С++ сервер работает на одном сокете строго последовательно (принял-отдал, принял-отдал).

V>На приеме в браузере в обработчиках onmessage детектируется номера ответов. В спокойных условиях порядок также не меняется, а вот если нагрузить сеть близко к 100%, то номера ответов в обратных вызовах onmessage иногда начинают перемешиваться — меняется порядок.
V>P.S. Браузер Chrome 80.0.3987.116

конечно вводных мало,
но например у меня похожая путаница была когда тупо стоял ре-коннектор на webscoket, а разборщик сообщений не учитывал момент реконнекта.
при нагруженной сети бывает что ws рвётся, поэтому простейший реконнектор не помешает...
Re[6]: WebSocket
От: Videoman Россия https://hts.tv/
Дата: 29.02.20 13:31
Оценка:
Здравствуйте, reversecode, Вы писали:

V>>...


Естественно я это все читал. И RFC читал. Меня интересует личный опыт людей которые сталкивались или не сталкивались с таким поведение.
Re[2]: WebSocket
От: Videoman Россия https://hts.tv/
Дата: 29.02.20 13:37
Оценка:
Здравствуйте, Aquilaware, Вы писали:

A>Посмею предположить, что ваш сервер неосознанно делает send из нескольких потоков в один сокет, Unix такое позволяет. В результате получаем race condition и "переупорядочивание" сообщений на принимающей стороне.


Точно нет. Сервер тупой как валенок — один поток, один сокет, последовательная обработка сообщений — вопрос — ответ.
P.S. Сейчас клиент сказал что у них обращение идет на WebSocket Proxy. Если причина, то в нем скорее всего.
Отредактировано 29.02.2020 13:45 Videoman . Предыдущая версия .
Re[4]: WebSocket
От: Videoman Россия https://hts.tv/
Дата: 29.02.20 13:48
Оценка:
Здравствуйте, Michael, Вы писали:

M>конечно вводных мало,

M>но например у меня похожая путаница была когда тупо стоял ре-коннектор на webscoket, а разборщик сообщений не учитывал момент реконнекта.
M>при нагруженной сети бывает что ws рвётся, поэтому простейший реконнектор не помешает...

Спасибо большое!!! Попадание 100%. Просто пока мало опыта у наших веб-программистов . При сильной загрузке рвалось соединение (а при работе с обычными сокетами, согласителсь, это не часто происходит) и глючила логика реконекта.

P.S. Интересно зачем сделано такое поведение ?!
Отредактировано 29.02.2020 13:54 Videoman . Предыдущая версия . Еще …
Отредактировано 29.02.2020 13:51 Videoman . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.