Как обрабатывать разные (url) соединения веб-сокетов в netty

Пример Websocket в netty (примеры) имеет обработчик HTTP-запросов, который:

  1. выполняет рукопожатие (сначала)

  2. (затем) обрабатывает различные типы фреймов WebSocket, в конечном итоге «TextWebSocketFrame».

В этом примере есть только один URL-адрес для подключения к веб-сокету.

Проблема в том, что когда начинается фактическая связь через веб-сокет на основе TextWebSocketFrame, нет прямого способа определить URL-адрес веб-сокета из самих TextWebSocketFrames (поправьте меня, если я ошибаюсь).

Итак, как обрабатывать разные (url) соединения через веб-сокеты в netty?

Одним из решений может быть регистрация каналов и их «URL-адресов подключения к веб-сокету» во время процесса установления связи.

Другой имеет только один URL-адрес подключения к веб-сокету и разрешает разные контексты, добавляя дополнительную информацию в сообщения веб-сокета (TextWebSocketFrames).

Я не нахожу эти решения элегантными, так что есть идеи?


websocket netty
person Ahmet Akyol    schedule 08.01.2012    source источник
comment
Я использую этот способ для работы с разными URL-адресами запросов. stackoverflow.com/a/47897963/14593844   -  person ferry133    schedule 24.03.2021

Ответы (1)


arrow_upward
1
arrow_downward

Насколько я понимаю, когда вы выполняете рукопожатие через веб-сокет, это относится к определенному URL-адресу. Это указано в стандарте веб-сокетов. См. RFC 6455. Следовательно, в TextWebSocketFrame нет информации об URL-адресе, поскольку предполагается, что кадр будет отправлен на URL-адрес, к которому привязан сокет.

Чтобы обрабатывать разные URL-адреса, вам необходимо:

  1. Настройте другой конвейер и привяжите к другому IP-адресу и/или порту для каждого URL-адреса или
  2. Как вы сказали, настройте рукопожатие и сохраните URL-адрес с каналом.

Лично я только что использовал JSON в TextWebSocketFrame. В моем JSON у меня есть поле, в котором указано предполагаемое действие. Это поле используется для маршрутизации к соответствующему обработчику сообщений.

Думаю, дело в дизайнерском решении. WebSockets предназначены для долгоживущих соединений, когда сообщение запроса может иметь 0, 1 или > 1 ответов. Это контрастирует с моделью 1 запроса и 1 ответа в стиле REST.

Надеюсь это поможет.

person Veebs    schedule 08.01.2012
comment
спасибо за ваш ответ и вашу реализацию RFC 6455 в netty. Я надеюсь, что вы, ребята, закончите Netty 3.3 и 4.0 очень скоро. - person Ahmet Akyol; 09.01.2012
comment
Нет проблем. На этом кодирование и (автобанное) тестирование веб-сокетов закончено. Осталось дождаться релиза. - person Veebs; 09.01.2012