работа с WebSocket в Ratchet и PHPDaemon

[grigori]

Я все выходные провел, изучая с большим удовольствием ratchet для web socket, и расстроился, когда прочел, что, пока писался ratchet со его отличной документацией, хипстеры просто взяли и депрекейтнули wamp - протокол общения с клиентами. теперь все будут жить по wamp2

основной js-либой для web socket называют autobahn, который сразу, как вышел wamp2, перестал поддерживать wamp1 вообще, для последнего осталась лишь старая версия 0.8.1

Аффторы ratchet забили на поддержку wamp2, вместо этого выкатили нечто по имени Thruway почти без документации, и вот они мы: тупиковая ветка эволюции с неподдерживаемой клиентской библиотекой, и технология будущего, брать которую я побаиваюсь.

 

[флоппик]

@grigori phpdaemon умеет последнюю версию вебсокета:
http://daemon.io/docs/en/#servers/websocket
http://daemon.io/docs/en/#clients/websocket

 

[grigori]

@grigori phpdaemon умеет последнюю версию вебсокета:
http://daemon.io/docs/en/#servers/websocket
http://daemon.io/docs/en/#clients/websocket

Спасибо, к сожалению, он ущербный

1. http://daemon.io/docs/en/#basics

Механизма взаимодействия между ребочими процессами не предусмотрено,

в отличие от https://github.com/reactphp/zmq

2. В документации нет примеров написания приложения на web socket, как http://socketo.me/docs/push а тратить месяц на изучение методом научного тыка я не готов.

 

[флоппик]

Эм, а зачем тебе между воркерами обмениватся инфой-то? Но вообще, это не совсем правда:
https://github.com/kakserpom/phpdaemon/blob/master/PHPDaemon/Examples/ExampleBroadcastCall.php

Пример с веб-сокетом:
https://github.com/kakserpom/phpdaemon/blob/master/PHPDaemon/Examples/ExampleWebSocket.php
Ну и вообще, https://github.com/kakserpom/phpdaemon/tree/master/PHPDaemon/Examples
там половина примеров - про вебсокеты.

Он на самом деле, сильно под веб-сокеты заточен, мне больше пришлось выковыривать всякую веб-сокетовую фигню из него, что бы работать просто с TCP =)

 

[grigori]

ты вот что скажи ты его юзал? там качество кода такое же, как как документация, или все-таки не падает?

 

[grigori]

Эм, а зачем тебе между воркерами обмениватся инфой-то?

2 реальные задачи:
1. получать файл на upload в php-fpm worker и сообщать его имя демону по сокету для обработки и отправки на S3
2. хочу получать сообщение для чата в php-fpm worker, обрабатывать с ORM, т.е. с блокирующими запросами к базе, и переваренное сообщение отдавать демону для раздачи в канале по web socket

проверять как этот демон потянет поддержку file upload не хочу, пусть этим занимаются nginx и fpm

 

[флоппик]

ты вот что скажи ты его юзал? там качество кода такое же, как как документация, или все-таки не падает?

Качество кода на порядок выше документации. Правда код местами написан Perl-readonly-style, но сейчас уже гораздо лучше, чем раньше. Работает на нескольких раздельных проектах, уже пару лет. За памятью и здоровьем воркеров следит сам (за что и выбрал), можно в коде втыкнутся почти в любое место логики на разных уровнях абстракции, но да, конечно документация совсем буэ. Это такая хардкорно-рабочая лошадка, короче.

 

[флоппик]

@grigori ну т.е. ты не между равноценными воркерами хочешь обмениватся инфой.) А то, что ты хочешь, можно просто реквестом решить к другому сервису внутри демона. У него внутри есть роуты (AppResolver), по правилам из которого твои реквесты попадают в нужный обработчик.
Т.е. ты не должен хотеть передавать конкретному воркеру данные (о чем и говорится в документации), но ессно можешь отправить реквест для любого свободного воркера, висящего на этом типе задач.

 

[grigori]

вынес в отдельную тему

 

[флоппик]

Оффтоп из оффтопа!

 

[grigori]

судя по

Пример с веб-сокетом:
https://github.com/kakserpom/phpdaemon/blob/master/PHPDaemon/Examples/ExampleWebSocket.php

в phpDaemon WAMP не реализован ни первый, ни второй - голые web sockets.
WAMP - это протокол на базе AJAX для реализации подписки-публикации, web sockets - транспорт вместо http.
для реализации wamp под phpdaemon гуглится только https://github.com/nizsheanez/yii2-websocket-application/blob/master/src/wamp/Route.php

Решения для фронта нет - поддержка соединения, переоткрытие при разрыве, все самому.

Глянь на пример Ratchet по ссылке - реализация полного стека: router, приложение, клиентская библиотека.

 

[флоппик]

судя по
WAMP - это протокол на базе AJAX для реализации подписки-публикации.

https://github.com/kakserpom/phpdaemon/blob/master/PHPDaemon/Examples/ExamplePubSub.php — не?

Клиента нет, это да.

А вот про

в отличие от https://github.com/reactphp/zmq

Там в реализации zmq под пхп стоооолько подводных камней, ты не представляешь )) Вот оно у меня тоже есть, и вот оно разваливается постоянно.

 

[grigori]

PhpDaemon - велосипед на коленке, а есть https://tools.ietf.org/html/draft-oberstet-hybi-tavendo-wamp-02
с реализациями на всех актуальных языках http://wamp-proto.org/implementations/
в том числе в готовых клиентских библиотеках, которую я писать самостятельно очень не хочу,
и есть вероятность, что именно это станет официальным стандартом

а про zmq расскажи немного подробнее, что с ним?

 

[флоппик]

Ну и ваще — не стреляй в пианиста: да, так бывает, что предложенное решение не подходит. У меня нет цели обосновывать обязательное применение пхпдемона в твоем конкретном случае (которого я все равно подробно не знаю, он у тебя там в голове). Не подходит — так не подходит.

 

[grigori]

Спасибо, это приятно, я исследовал его.
Я помню как Зорин аннонсировал свой пакет здесь много лет назад, и PHPDaemon мог бы быть основным асинхронным фреймворком.
Жаль, что он тогда не захотел услышать наши комментарии. Как следствие, phpdaemon остается чем-то наколеночным, не соответствующим стандартам, и на фоне ratchet уже выглядит устаревшим.

я пишу для других интересующихся что к чему

а какие проблемы с zmq?

 

[флоппик]

а какие проблемы с zmq?

Про другие схемы не скажу, но вариант с request-reply broker при росте коннектов в определенный момент делает финт ушами: роутер делал внезапно 100% проца на одно ядро ( вместо 2-3%), дилеры переставали получать пакеты вообще.
При этом у меня в роутере буквально одна строчка с запуском ProxyDevice. Впрочем, вариант с ручной обработкой поллера делал то же самое. При этом трафик был небольшим сравнительно: тыщи полторы клиентов, и воркеры отвечали почти мгновенно. Пришлось делать лоад-балансинг перед роутером.

Воткнутся в zmq-шный evloop самому - ничем тоже нельзя особо. Там есть шаманские танцы с получением файлового дескриптора и мониторинга уже его (как раз его использует reactphp: https://github.com/reactphp/zmq/blob/master/src/SocketWrapper.php#L49) но оно недокументировано нормально, и! местами сломано для IPC! (как раз для чего ты его и показывал: https://github.com/mkoppanen/php-zmq/issues/130)

Мемлики. Что приводит нас к необходимости рестартовать процессы изредка. А zmq страдает от late joiner syndrome - что не успел получить ни один из дилеров — пропало.

При этом у меня схема работы с zmq каноничная прям до того, что можно с мануала копипастить код.

 

[флоппик]

Я помню как Зорин аннонсировал свой пакет здесь много лет назад, и PHPDaemon мог бы быть основным асинхронным фреймворком.
Жаль, что он тогда не захотел услышать наши комментарии. Как следствие, phpdaemon остается чем-то наколеночным, не соответствующим стандартам, и на фоне ratchet уже выглядит устаревшим.

Да. Особенно печально это именно потому, что когда я выбирал, я бы тоже с удовольствием писал бы на на ratchet / reactphp - но оказалось, что phpdaemon тупо уделывает их всех по надежности. Ну прям, на порядки. И тогда стабильность перевесила недостатки в виде отсутствия документации (тогда вообще полного) и лапшекода а-ля ассемблер. Ну да что поделать...

 

[grigori]

у тебя были проблемы со стабильностью react/ratchet?

в принципе, все это решается еще одним уровнем абстракции - rabbitmq/redis для ipc, какой-нибудь специальный демон для web socket router вроде crossbar или wiola, но я стремлюсь к минимизации количества элементов

 

[флоппик]

у тебя были проблемы со стабильностью react/ratchet?

Да. Ноги проблемы кстати везде общие — пхп течет памятью, экстеншны текут, если ты хочешь больше чем 1 воркер на ядро, ты начинешь форкать (запускать дубли, whatever), и теперь у тебя куча одновременно подтекающих процессов, и все это надо мониторить на память... в phpdaemon я в конфиге написал что max-memory = 2g и подтекающий воркер плавно сам рестартанет (да, graceful, перестанет принимать соединения, новый воркер возьмет его работу, старый потихоньку все отработав умрет) и я не пишу кучу кода для слежения за памятью, кол-вом запросов, открытыми дескрипторами...(что мне пришлось написать для версии c zmq, и там до сих пор взводы багов маршируют по моим ощущениям) это все Зорин за меня написал уже, ага, оно просто работает.

Я не спорю, я когда начинал писать, было php 5.3 меcтами переходящий в 5.4, и с тех пор, особенно в 5.6 - почти ничего не течет... почти.

 

[флоппик]

в принципе, все это решается еще одним уровнем абстракции - rabbitmq/redis для ipc, какой-нибудь специальный демон для web socket router вроде crossbar или wiola, но я стремлюсь к минимизации количества элементов

Ну ессно, решается. У меня была версия даже, где я роутер zmq написал на питоне, оставив воркеры на пхп ) Проблема в том, что инфраструктуру писать весело, но непроизводительно. Хорошо когда кто-то до тебя про всем этим граблям прошел. )