Как обрабатывать различные (URL) веб-сокет соединения в Netty - PullRequest
Новая
       14

Как обрабатывать различные (URL) веб-сокет соединения в Netty

1 голос
/ 08 января 2012

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

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

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 09 января 2012

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

Для обработки различных URL-адресов вам потребуется:

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

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

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

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

...