Long data to AsyncTcp

[TheoAl]

В примере integraion2, если запустить большое количество коротких сообщений на локальный tcp сервер, то сообщения будут буферизироваться и будут прилетать в worker в одном по два и более, в итоге не получится адресовать сообщение, json не разбирётся корректно.

Если же сообщения будут>65K симоволов, то их разобьёт, целостность сообщения потеряется. Воспроизводится запуском цикла stream_socket_client и fwrite с различной длинной сообщений в пару потоков.

[morozovsk]

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

Прямо на главной странице воркермана есть пример того что вам нужно. Настоятельно рекомендую прочитать хотя бы главную страницу библиотеки, которую вы собираетесь использовать.
Если всё так лень читать всю страницу, то вот ссылка на то что нужно:
https://github.com/walkor/Workerman#custom-protocol
Но если вы зарегистрировались на гитхабе, чтобы завести тикет, то значит ещё не всё потеряно :)

Также рекомендую совместно с воркерман использовать ev.
О том насколько он ускоряет работу я писал в своей статье на хабре.

[TheoAl]

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

[morozovsk]

Можно конечно и свои костыли писать, но помоему пример с MyTextProtocol вполне рабочий. Он гарантирует разбиение на пакеты по "\n", а в моём примере интеграции я отправляю "\n" после каждого json.
Позже, когда у меня появится время, я добавлю MyTextProtocol в пример интеграции 2, чтобы код был больше пригоден для продакшена и видимо ещё статью надо будет подправить. Короче, это будет нескоро :)

[TheoAl]

Там в коробке есть протокол text://. Который ровно так и написан, можно пользовать его, т.е. поменять "tcp://127.0.0.1:1234" на "text://127.0.0.1:1234" и более озвученых выше проблем не возникнет по крайней мере для коротких сообщений (вероятно возникнут другие, пока не думал чем это чревато). Также можно соединяться напрямую с WS сервером исключая TCP из схемы, и, там уже, onMessage решать вопрос доставки получателю или всем соединениям. (для второго придётся правда написать отдельную реализацию rfc6455 если хотеть соединяться из "иных" серверных мест, но это тоже вполне не сложно)

[morozovsk]

спасибо. "text://127.0.0.1:1234" мне подойдёт.