Pull to refresh

Comments 26

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

Об этом сказано в спецификации HTTP.
Да, именно там я это и увидел, ну естественно после того как наткнулся на приведенную ссылку. Но изначально я изучал только спецификацию вебсокетов, наивно предполагая, что этого будет достаточно.
В своё время тоже делал свою реализацию протокола WebSocket средствами СУБД Caché, правда для 76 и 07 версии.
Но с внедрением нативной поддержки RFC 6455 необходимость в велосипеде отпала.
у меня при реализации, сообщения с сервера приходили в юникоде, причём браузер его не распознавал, соответственно понадобилась дополнительная функция на стороне клиента для декодирования.
А разве стандарт не упоминает про необходимость кодировки UTF-8?
не забудьте убрать лидирующие и конечные пробелы
Лидирующие? Где они лидируют? «Начальные», наверное?
вы ни разу не встречали слово «лидирующий» в таком значении? правда?
Я много чего встречал, например, «котельная трубочка» (вместо «коктейльная») или «паническая атака» (вместо «приступ паники»), это ещё не значит, что у слова «лидирующий» есть такой смысл. На мой взгляд, это калька с английского.
Смысл моей ошибки заключался в том, что браузер принимает заголовок с завершающей пустой строкой, а так как я ее не отправлял (ну не нашел в документации про это ни слова),…

Протокол Websockets, его первая фаза (http://ru.wikipedia.org/wiki/WebSocket) идет поверх HTTP, а в Спецификации НTTP, ясно сказано, что заголовок и тело разделяется пустой строкой.
У нас проект на php.
К сожалению, особенностей (конкретной реализации)WS серверов так много, что проще взять nodejs и работать с WS через неё. Даже простым exec-ом (если совсем что-то простое).
Нет ни одной библиотеки на php такого уровня, как уже довольно давно существующие пакеты для ноды.
Важно: все строчки выше применимы, когда вы пишете клиент!
Если вы пишите сервер, то «это уже совсем другая история»
на PHP принципиально плохо что либо реализовывать для работы с WEBсокетами. Это связано с тем, что РНР предназначен для режима Запрс-Ответ… А работа с WEBсокетами предполагает долгосрочную жизнь процесу. Если работаем через nginx, то он проксирует все WEBсокетами. запросы на демон. т.е. мы должны запустить наш сервер, как отдельный демон.
В этом есть конечно свои плюсы, так и минусы. Недавно была переводная статья «РНР рожден, чтобы умереть», спорная конечно, но кое-что в ней подмечено верно. Хотя, в своих демонах я утечек памяти не наблюдал: специально был реализован мониторинг и по памяти в том числе.
проблема php не в утечках, а в объеме занимаемом одним процессом. Т.к. php тянет все расширения в статику а не выделяет память по мере необходимости.
да, я в курсе всех проблем РНР
по этому нам приходится websockets пилить на Сях
PhpDaemon на тесте себя вполне нормально показывал. До продакшена, правда, не дошло, но не из-за проблем на сервер-сайде.
мы родили своего Демона :).
PhpDaemon — хорош, но там много «лишнего кода». Так что наши демоны себя в продакшене показывают довольно-таки не плохо.
Ну, он создан как универсальный фреймворк для демонов любых типов. естественно, что решение под конкретные задачи будет лучше.
Вот тут конечно они сильно замудрили.
Это стандартный спосои кодирование передаваемых данных… Перед данными устанавливается 3 бита длинны данных, далее идет длинна 1-3 байта, потом сами данные.
Такие приемы актуальны в очень медленных, либо в сильно завязанных на время каналах. В чем смысл экономии 3 байт в TCP-запросах мне не совсем понятно. И зачем 64-битная длина фрейма, террабайты данных туда-сюда гонять пока никто не планирует.
Как-то я тоже реализовал вебсокет-сервер на гипертекстовом препроцессоре, наступив на все упомянутые Вами грабли. Итоговый двухколёсный демон был непредсказуем и очень неудобен в поддержке. После чего для таких вещей я перешёл на python, о чём ни разу не жалею.

Связка Tornado + Tornadio + Socket.io чудесно работает с веб-сокетами из коробки, поддерживает кучу других транспортов (graceful degradation), красива, логична, поддерживается огромным коммьюнити. И показательно, кстати, что для Socket.io не существует ни одного php-бэкэнда.
О, спасибо за напоминание! Надо бы дописать библиотечку (забросил на стадии интерфейсов fork/pthreads).
Wow! Нашелся некто умный, кто уже написал библиотечку, но в силу своей сволочности зажопил выложить ее!
Обновил топик. Переработал функцию hybi10Decode(), чтобы она разделяла подрял идущие фреймы.
Ставить плюс уже поздно, но большое спасибо!
Перерыл весь интернет, реализовывая вебсокеты на php-проекте, но только эта статья (а особенно спойлер!) помогли решить проблему окончательно.
Благодарю!
У меня проблема с флагами RVS1, RVS2, RVS3 уже очень долго ответ не могу найти. Я реализую свой WebSocket сервер на С++ и всё хорошо работает, но когда время между отправкой сообщений из браузера на сервер маленькое (меньше 50 миллисекунд) то фреймы приходящие сначала начинают приходить вместе то есть в одном принимаемом сообщении 2 и более фреймов умещается но это мелочь, потом браузер присылает фрейм с не нулевыми значениями RVS1, RVS2, RVS3 и я не знаю как такие декодировать, в итоге соединение приходится закрывать соединение.
Использую Sec-WebSocket-Version 13
К сожалению с момента публикации я практически не занимался сокетами, и помочь, наверно, не смогу.
Sign up to leave a comment.

Articles