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

[fixxxer]

Не, мне не надо чатик, чатик я вообще особо не думая написал на reactphp + angular, работает, чо.

Я об этом всем думаю в контексте isomorphic javascript.

 

[hell0w0rd]

@fixxxer, а нафига тебе сложные части на JS? Чтобы небыло зоопарка?
Просто JS неплохо ставить в роли роутера/прокси. Если надо просто сделать запрос в базу - ок. Если надо написать мудреную логику - на любителя.
Напиши api на любимом языке, а isomorphic сервер пускай его дергает.

 

[fixxxer]

Чтобы работать с бизнес-логикой в рамках event-based FSM.

 

[grigori]

в приницпе, мне WAMP понравился для удобного ipc, поддержка настоящего rpc искаропки
прикольно, что можно не думать о протоколе: одной строкой регишь метод в одном клиенте, другой строкой вызываешь этот метод из другого клиента, в первом клиенте получаешь ответ, все

а вот насчет fsm - тут вопрос, не пытаешься ли ты объять необъятное? мне кажется, что архитектура, когда клиент, роутер и обработчик - отдельные процессы, естественна,
она работает и в http/1 (браузеры-ngnx-fpm), и в http/2 (браузеры-роутер-бекенд)

php для разработки обработчиков подходит прямо искаропки, для java и python есть хорошая инфраструктура, js - просто не подходит, ts - нормально, но в руке нужно держать бубен

совмещать роутер с обработкой можно, но применение этого ограничено, и непонятно ради чего - проще не становится

 

[fixxxer]

не пытаешься ли ты объять необъятное?

Почему? Что такого необычного в желании работать с domain model в рамках FSM архитектуры? Что в ней такого особенного?

 

[grigori]

если я правильно понимаю, fsm обычно реализуется в посреднике - часть в конфиге nginx, часть в роутинге приложения,
а domain model - это вызовы моделей контроллером приложения и друг другом,
то есть fsm идет перед dm и четко от него отделено

 

[fixxxer]

Я тебя не понимаю.
Если есть какой-то специфический сервис, который в основном держит данные in memory или работает со своей собственной базой данных, а обратиться к основному приложению ему надо лишь иногда - это одно, с этим все понятно, тут отдельно всегда и делали.
Я же говорю о ситуации, когда необходимо в основном приложении поддерживать постоянные соединения (неважно, лонг-поллинг, вебсокеты или какой-то кастомный протокол over tcp). Что отделено-то? Если работу с хранилищами и прочим унести в классическое prefork приложение, так весь смысл теряется - туда все равно будет запрос на каждый пук. Если нет, то я вообще не понимаю.

 

[grigori]

я не уверен в том, что ты называешь классческим prefork-приложением, и что такое запросы, которые будут на каждый пук
если ты про php-fpm, тогда - нет, я о другом

Если работу с хранилищами и бизнес-логикой унести в отдельный процесс - ничего не меняется.
Роутер занят обеспечением работы протокола, а приложение - логикой.
Запросов нет вообще - взаимодействие строится на rpc-вызовах поверх дуплексного соединения. Приложение - клиент, user agent - клиент, роутер - сервер. Зарегистрировать и вызвать процедуру может любой клиент, пермиссии определяются ролью. Запросов нет, только процедуры.

 

[hell0w0rd]

@grigori, он хочет состояние держать в памяти, как я понял. И при его изменениях сразу уведомлять клиентов, ведь основная прелесть вебсокетов, на мой взгляд, что ты можешь пнуть клиента, а не клиент тебя.

 

[grigori]

@hell0w0rd, нет никаких клиентов

 

[флоппик]

@grigori так кого выбрал-то?

 

[grigori]

@флоппик, сначала роутер crossbar, и PubSub / RPC на JS в браузерах, без server-side,
просто служебный канал для rpc-вызовов, где клиенты будут сами друг друга опрашивать для составления списка участников, вопрос безопасности сейчас не стоит

 

[флоппик]

А то мне тут похоже тоже надо будет что-то похожее набросать. Пойду под пхпдемон реализацию WAMPv2 напишу, что-ли

 

[grigori]

https://github.com/crossbario/crossbarexamples/tree/master/authenticate/wampcradynamic/php
вот, вроде, сделали

 

[флоппик]

Трувей же использует?

 

[grigori]

да, но я решил не использовать thruway как роутер, только как клиент с backend-логикой,
надо будет потестировать его сначала
а заменить crossbar на thruway будет легко, протокол и настройки у всех одинаковые

 

[hell0w0rd]

@grigori, а ты на socketcluster не смотрел?

 

[grigori]

@hell0w0rd, не, но описание крутое - Process crashes, lost connections and other failures are handled seamlessly.
потери на сбоях - главная головная боль

 

[hell0w0rd]

@hell0w0rd, не, но описание крутое - Process crashes, lost connections and other failures are handled seamlessly.
потери на сбоях - главная головная боль

да потери на сбоях тот же socket.io умеет. А вот встроенная поддержка многоядерности (cluster) и возможность послать ответ - крутые фичи.
Единственное сегодня в код глянул, автор признался, что не любит юнит-тесты и код покрыт только интеграционными тестами на 300 строк кода. В общем странновато.

 

[grigori]

Я не вижу в чем достоинство с масштабируемостью - сама pub/sub архитектура подразумевает множество подписчиков на задачи, запускай сколько хочешь.
Еще я не увидел поддержку стандартов - того же wamp, например. Протокол дает независимость от языка.