Mojolicious: использовать один веб-сокет или несколько?

Я изучаю Mojolicious и веб-сокеты. Пока у меня есть веб-страница, которая отображает строки из базы данных и имеет кнопки для добавления, удаления и обновления строк, а также для выбора столбцов для сортировки.

На данный момент он использует «одноразовые» веб-сокеты в обработчиках javascript «onclick» для каждой кнопки, и это работает.

Будет ли это больше соответствовать намерению веб-сокетов, чтобы сокеты оставались живыми и использовались для нескольких кликов? Я думаю, что ответ должен быть «да», потому что в противном случае он станет беспорядочным, если пользователь быстро нажмет кнопку несколько раз.

И, как вопрос стиля, должен ли я иметь только один веб-сокет, который обрабатывает различные типы взаимодействия между браузером и сервером, или отдельные веб-сокеты для каждого типа? Наличие одного веб-сокета потребует кода для анализа сообщений и принятия решения о том, что с ними делать. Принимая во внимание, что несколько веб-сокетов были бы проще, но это потребовало бы повторения кода обработки ошибок и т. д.

Я знаю, что это многословный и философский вопрос, но я хочу получить общую форму приложения, прежде чем приступать к его дальнейшей разработке.


javascript websocket perl mojolicious mojolicious-lite
person Chris Dennis    schedule 28.01.2015    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Вызов Ajax — это эффективный способ для клиента запросить определенную информацию с сервера в однократном подходе.

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

Использование одноразового веб-сокета (где вы создаете веб-сокет, используете его, а затем закрываете) для случайного запроса данных от клиента к серверу — не самый оптимальный способ сделать что-то, потому что существуют дополнительные накладные расходы на настройку веб-сокета, который отсутствует в вызове ajax, поскольку обе стороны договариваются о том, поддерживают ли обе стороны веб-сокеты и соглашаются изменить протокол с http на веб-сокет.

Одноразовое соединение через веб-сокет будет выглядеть так:

  1. клиент устанавливает TCP-сокет на сервер
  2. клиент отправляет начальный HTTP-запрос с заголовками обновления webSocket
  3. сервер отвечает, что можно перейти на протокол webSocket
  4. клиент отправляет сообщение
  5. сервер получает сообщение и отправляет ответ
  6. клиент получает ответ
  7. клиент закрывает TCP-соединение

Вызов Ajax будет выглядеть так:

  1. клиент устанавливает TCP-сокет на сервер
  2. клиент отправляет HTTP-запрос на сервер
  3. сервер получает запрос и отправляет ответ
  4. клиент получает ответ
  5. клиент закрывает соединение

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

Таким образом, если вы просто запрашиваете какую-то информацию с сервера по клику конечного пользователя, то вполне вероятно, что вызов Ajax является более эффективным подходом (и более простым в реализации).

person jfriend00    schedule 29.01.2015
comment
Спасибо. В этом есть смысл. - person Chris Dennis; 29.01.2015

arrow_upward
1
arrow_downward

Прочитав немного больше по теме и поигравшись с кодом, я пришел к следующему выводу:

  1. Это зависит от того, что вы пытаетесь сделать. Как всегда.
  2. Как говорит jfriend00, Ajax, вероятно, хорош для одноразовых сообщений.
  3. Для моих нужд лучше использовать один постоянный веб-сокет. Это сокращает повторение кода, но означает, что мне придется изобретать собственную простую последовательность команд/ответов для работы с сообщениями.

Чтобы веб-сокет оставался открытым, я адаптировал Идея Джона Генри.

person Chris Dennis    schedule 30.01.2015