WebSocket (Sec-WebSocket-Version: 13) — тонкости реализации, в частности на PHP

[friday]

> ну не нашел в документации про это ни слова

Об этом сказано в спецификации HTTP.

[metis]

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

[servitRM]

В своё время тоже делал свою реализацию протокола WebSocket средствами СУБД Caché, правда для 76 и 07 версии.
Но с внедрением нативной поддержки RFC 6455 необходимость в велосипеде отпала.

[Slavenin999]

у меня при реализации, сообщения с сервера приходили в юникоде, причём браузер его не распознавал, соответственно понадобилась дополнительная функция на стороне клиента для декодирования.

[servitRM]

А разве стандарт не упоминает про необходимость кодировки UTF-8?

[bolk]

не забудьте убрать лидирующие и конечные пробелы

Лидирующие? Где они лидируют? «Начальные», наверное?

[kaichou]

вы ни разу не встречали слово «лидирующий» в таком значении? правда?

[bolk]

Я много чего встречал, например, «котельная трубочка» (вместо «коктейльная») или «паническая атака» (вместо «приступ паники»), это ещё не значит, что у слова «лидирующий» есть такой смысл. На мой взгляд, это калька с английского.

[Arks]

\0 нормальное окончание строк в С. ru.wikipedia.org/wiki/%D0%9D%D1%83%D0%BB%D1%8C-%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%BE%D0%BA%D0%B0

[akalend]

Смысл моей ошибки заключался в том, что браузер принимает заголовок с завершающей пустой строкой, а так как я ее не отправлял (ну не нашел в документации про это ни слова),…

Протокол Websockets, его первая фаза (http://ru.wikipedia.org/wiki/WebSocket) идет поверх HTTP, а в Спецификации НTTP, ясно сказано, что заголовок и тело разделяется пустой строкой.

[la0]

У нас проект на php.
К сожалению, особенностей (конкретной реализации)WS серверов так много, что проще взять nodejs и работать с WS через неё. Даже простым exec-ом (если совсем что-то простое).
Нет ни одной библиотеки на php такого уровня, как уже довольно давно существующие пакеты для ноды.
Важно: все строчки выше применимы, когда вы пишете клиент!
Если вы пишите сервер, то «это уже совсем другая история»

[akalend]

на PHP принципиально плохо что либо реализовывать для работы с WEBсокетами. Это связано с тем, что РНР предназначен для режима Запрс-Ответ… А работа с WEBсокетами предполагает долгосрочную жизнь процесу. Если работаем через nginx, то он проксирует все WEBсокетами. запросы на демон. т.е. мы должны запустить наш сервер, как отдельный демон.
В этом есть конечно свои плюсы, так и минусы. Недавно была переводная статья «РНР рожден, чтобы умереть», спорная конечно, но кое-что в ней подмечено верно. Хотя, в своих демонах я утечек памяти не наблюдал: специально был реализован мониторинг и по памяти в том числе.

[Arks]

проблема php не в утечках, а в объеме занимаемом одним процессом. Т.к. php тянет все расширения в статику а не выделяет память по мере необходимости.

[akalend]

да, я в курсе всех проблем РНР
по этому нам приходится websockets пилить на Сях

[VolCh]

PhpDaemon на тесте себя вполне нормально показывал. До продакшена, правда, не дошло, но не из-за проблем на сервер-сайде.

[akalend]

мы родили своего Демона :).
PhpDaemon — хорош, но там много «лишнего кода». Так что наши демоны себя в продакшене показывают довольно-таки не плохо.

[VolCh]

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

[akalend]

Вот тут конечно они сильно замудрили.
Это стандартный спосои кодирование передаваемых данных… Перед данными устанавливается 3 бита длинны данных, далее идет длинна 1-3 байта, потом сами данные.

[theaspin]

Такие приемы актуальны в очень медленных, либо в сильно завязанных на время каналах. В чем смысл экономии 3 байт в TCP-запросах мне не совсем понятно. И зачем 64-битная длина фрейма, террабайты данных туда-сюда гонять пока никто не планирует.

[ebt]

Как-то я тоже реализовал вебсокет-сервер на гипертекстовом препроцессоре, наступив на все упомянутые Вами грабли. Итоговый двухколёсный демон был непредсказуем и очень неудобен в поддержке. После чего для таких вещей я перешёл на python, о чём ни разу не жалею.

Связка Tornado + Tornadio + Socket.io чудесно работает с веб-сокетами из коробки, поддерживает кучу других транспортов (graceful degradation), красива, логична, поддерживается огромным коммьюнити. И показательно, кстати, что для Socket.io не существует ни одного php-бэкэнда.

[Eddy_Em]

О, спасибо за напоминание! Надо бы дописать библиотечку (забросил на стадии интерфейсов fork/pthreads).

[Eddy_Em]

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

[metis]

Обновил топик. Переработал функцию hybi10Decode(), чтобы она разделяла подрял идущие фреймы.

[nswbit]

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

[Levhav]

У меня проблема с флагами RVS1, RVS2, RVS3 уже очень долго ответ не могу найти. Я реализую свой WebSocket сервер на С++ и всё хорошо работает, но когда время между отправкой сообщений из браузера на сервер маленькое (меньше 50 миллисекунд) то фреймы приходящие сначала начинают приходить вместе то есть в одном принимаемом сообщении 2 и более фреймов умещается но это мелочь, потом браузер присылает фрейм с не нулевыми значениями RVS1, RVS2, RVS3 и я не знаю как такие декодировать, в итоге соединение приходится закрывать соединение.
Использую Sec-WebSocket-Version 13

[metis]

К сожалению с момента публикации я практически не занимался сокетами, и помочь, наверно, не смогу.