Как понять, по какому маршруту было отправлено сообщение websocket клиентом на сервере?

Я собирал сервер и, пытаясь реализовать протокол веб-сокета, столкнулся с проблемой.

Как следует из заголовка вопроса, предположим, я определил два маршрута (/ws1, /ws2), которые предоставляют несколько подключений к веб-сокетам.

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

Основная проблема заключается в том, что когда клиент отправляет последующее сообщение веб-сокета, как сервер поймет, на какую конечную точку было отправлено сообщение веб-сокета.

Прочитав это: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers Насколько я понимаю, в сообщении нет такого поля, которое обозначает маршрут.

На всякий случай: я делаю это на PHP.


php websocket phpwebsocket
person Ikari    schedule 22.08.2016    source источник
comment
Веб-сокет похож на трубу. После успешного рукопожатия между двумя точками маршрут устанавливается. Запрос всегда возвращается к точке, из которой он был сделан.   -  person Jay Blanchard    schedule 22.08.2016

Ответы (2)


arrow_upward
1
arrow_downward

Соединение WebSocket устанавливается с помощью HTTP-запроса GET, который обновляет соединение. Вы можете идентифицировать клиентов на основе идентификатора ресурса в PHP, приведя ресурс к целому числу, используя (int) $resource.

Соединения TCP обычно идентифицируются по четырем IP-адресам источника/порта-источника/IP-адреса назначения/порта назначения.

Вы должны хранить информацию URI/конечной точки в массиве или аналогичной структуре данных и использовать идентификатор клиента в качестве индекса. Затем вы можете искать конечную точку при получении новых сообщений.

person kelunik    schedule 22.08.2016

arrow_upward
2
arrow_downward

Маршрут никогда не меняется после завершения рукопожатия. Идея состоит в том, что WebSocket поддерживает соединение с полным состоянием, но это соединение сначала согласовывается по HTTP. Это делается путем отправки обычного HTTP-запроса на URI, после чего конечная точка отвечает за поддержание соединения после успешного согласования.

Таким образом, вы несете ответственность за отслеживание информации в этом первоначальном HTTP-запросе после согласования соединения WebSocket, если вы хотите использовать его в дальнейшем.

Если вы посмотрите, как это делают некоторые текущие реализации серверов WebSocket на PHP, например Ratchet PHP, вы увидите, что вещь, которая обрабатывает запросы WebSocket, получает объект GuzzleHttp после успешного согласования соединения в обработчике обратного вызова onOpen. Он содержит всю исходную информацию HTTP-запроса, связанную с объектом подключения клиента, поэтому вы можете продолжать использовать ее повсюду.

Таким образом, объект Connection содержит всю информацию о самом TCP-сокете, обеспечивающем насыщение, в сочетании с объектом HTTP, который может быть реализован как что-то вроде GuzzleHttp или PSR7 Message объект. Каждый раз, когда от этого объекта Connection принимается сообщение, связанный объект HTTP может получить доступ для поиска соответствующей строки запроса из исходного HTTP-запроса.

person Sherif    schedule 22.08.2016