Что лучше: несколько конечных точек веб-сокетов или одна конечная точка веб-сокета в Java EE7

Java EE 7 позволяет очень легко создавать новые конечные точки с помощью аннотаций. Тем не менее, мне было интересно, будет ли хорошей идеей иметь несколько конечных точек для обработки каждого типа сообщений, или мне нужно иметь только один фасад конечной точки для всего?

Я склоняюсь к тому, чтобы иметь один единственный фасад конечной точки, основанный на теории, согласно которой каждая конечная точка создает новое соединение сокета с клиентом. Однако эта теория может быть неверной, и веб-сокет может быть реализован так, что он будет использовать только одно соединение сокета TCP/IP независимо от того, сколько конечных точек веб-сокета подключено, если они подключаются к одному и тому же хосту: порту.

Я спрашиваю конкретно о Java EE 7, так как могут быть другие реализации сервера веб-сокетов, которые могут делать что-то по-другому.


websocket java-ee-7
person Archimedes Trajano    schedule 24.06.2013    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Единственным правильным ответом здесь является последний вариант — наличие нескольких конечных точек.

См. спецификацию WebSocket, глава 2.1.3:

API ограничивает регистрацию MessageHandlers на сеанс до одного MessageHandler на собственный тип сообщения веб-сокета. [WSC 2.1.3-1] Другими словами, разработчик может зарегистрировать не более одного обработчика сообщений для входящих текстовых сообщений, один обработчик сообщений для входящих двоичных сообщений и один обработчик сообщений для входящих сообщений pong. Реализация веб-сокета должна генерировать ошибку, если это ограничение нарушается [WSC 2.1.3-2].

Что касается использования или неиспользования нескольких TCP-соединений - AFAIK в настоящее время будет новое соединение для каждого клиента, и нет простого способа заставить что-либо еще. мультиплексирование WebSocket должно решить эту проблему, но я не думаю, что любая реализация WebSocket API поддерживает это (могу ошибаться..)

person Pavel Bucek    schedule 09.08.2013
comment
Это на самом деле отвечает на вопрос, который я задал выше из-за неоднозначности словесных типов сообщений. - person Archimedes Trajano; 11.07.2014
comment
Извините, ребята, я немного медлительный, поэтому, если я использую несколько конечных точек, будет только одно открытое соединение для каждого клиента или соединение для каждой конечной точки? - person andresscode; 23.11.2017
comment
соединения на конечную точку. Был черновой вариант RFC для мультиплексирования, но он так и не был завершен (tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11). - person Pavel Bucek; 03.12.2017

arrow_upward
8
arrow_downward

Только что заметил двусмысленность в моем вопросе о типах сообщений. Когда я говорю о типах сообщений, я имею в виду различные типы сообщений приложений, а не собственные типы сообщений, такие как «бинарные» или «текстовые». Таким образом, я отметил ответ @PavelBucek как принятый.

Тем не менее, я попробовал эксперимент с Glassfish и двумя конечными точками. Мои подозрения были верны и что для каждой подключенной конечной точки установлено TCP-соединение. Это может вызвать большую нагрузку на сервер, если на одной странице используется более одной конечной точки веб-сокета.

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

Это будет означать, что приложение должно выполнять диспетчеризацию, а не полагаться на какой-то API более высокого уровня, который сделает это за нас.

person Archimedes Trajano    schedule 11.07.2014