Модель обработки серверов веб -сокетов

Question

Для реализации сервера, поддерживающих клиентов, используя Веб -розетки, сохраняют ли серверы открытое HTTP -соединение с каждым клиентом? Как этот масштаб?

Каковы «модели программирования» при реализации этого типа сервера? IE: большинство веб-приложений имеют сервлеты и т. Д., Которые поддерживают Connect-> request-> response-> модель типа Close. В то время как с веб -гнездами Connect остается открытым на неопределенный срок.

Answer 1

Как правило, нужно работать в асинхронный модель для этих долгоживущих соединений с работой. Есть несколько различных методов для асинхронного ввода -вывода; Все это имеют свои преимущества и недостатки.

Тот, который уже должен быть знаком всем, кто работал с JavaScript и Аякс Модель обратного вызова; в котором вы отправляете запрос и устанавливаете обратный вызов, который будет вызван, когда он завершается. Вот как XMLHTTPRequest Работает, не блокируя все остальные страницы, пока они ждут, пока запрос одной страницы закончит. Так также как Искаженный Смеет Python Network Framework работает, хотя она может вызовать методы на объектах или функциях обратного вызова в зависимости от используемых вами интерфейсов.

Другая мощная модель - это Эрланг Подход стиля, называемый моделью актера, имеет много, много легких процессов (например, потоков, но без общего состояния), каждый из которых общается друг с другом через асинхронные сообщения. Средство выполнения Erlang была реализована, чтобы сделать нерестовые тысячи процессов очень эффективными; Тогда у вас может быть просто один процесс для каждого соединения и попросить их отправлять сообщения в другие процессы, реализующие бэкэнд вашего приложения. Процессы Erlang также могут быть автоматически запланированы в нескольких потоках ОС, чтобы в полной мере воспользоваться многоядерными системами. Эджабберд, популярный сервер Jabber (протокол чата, который требует много долгоживущих открытых соединений), реализован в Erlang, как и Система чата в Facebook.

Новый GO Язык Из Google используется аналогичный подход, ближе к сообщению Hoare, чем модель актера Эрлана, но которая имеет много сходства.

В Mac OS X 10.6 Apple представила Гранд Центральная отправка, наряду с блоками (по существу закрытия) в C, C ++ и Objective-C. Это позволяет что-то вроде модели обратного вызовов, управляемой событиями AJAX или Twisted Style, но с явно управляемыми очередями, которые выполняются последовательно для управления доступом к общим ресурсам в многопоточной многоядерной среде. Twisted и JavaScript запускают однопоточные резьбы, и поэтому могут воспользоваться только одним ядром, если вы не используете несколько процессов операционной системы, которые могут быть довольно тяжелыми и увеличить затраты на связь между ними.

Тогда есть более традиционные модели, такие как Unix select функция или более современный и способный epoll или же kqueue(). Анкет В них, как правило, у вас есть основной цикл в вашей программе, которая устанавливает кучу событий для наблюдения (сетевой ввод -вывод возвращает еще несколько данных, ввод -ввод файлов возвращает больше данных, создается новое сетевое соединение и т. Д.) , а затем вызывает системный вызов, который блокирует до тех пор, пока не произойдет одно из этих событий, после чего вы проверяете, какой из них произошел, а затем обрабатывает его надлежащим образом. Эти системные вызовы обычно используются для обеспечения структур более высокого уровня, описанных выше.

Для очень хорошего обзора ошеломляющего множества доступных вариантов (сосредоточенное на более традиционных и более низких уровнях подходов UNIX), см. Проблема C10K, обзор различных методов помощи в работе с 10 000 одновременных связей одновременно. Это также имеет хороший список библиотек C и C ++ для абстрагирования различных доступных API, таких как либевент.

Последний вариант, конечно, - использовать один процесс или один поток ОС для каждого соединения. Проблема в том, что процессы очень тяжелые, а даже нити довольно тяжелый вес по сравнению со многими из этих вариантов. В целом, для наилучшей производительности вы хотели бы иметь один процесс или поток на процессор, каждый из которых использует асинхронное API ввода -вывода, чтобы выяснить, когда он должен выполнять работу, а затем отправлять эту работу на один из нескольких объектов или обратных вызовов которые были зарегистрированы для обработки соединений, или одного из нескольких легких процессов в стиле Эрланг, которые ждут сообщения, или что -то в этом роде.

В качестве примечания, соединение в веб -розетках не является HTTP -соединениями, а новым протоколом, Протокол WebSocket, хотя вы можете использовать тот же порт, что и HTTP, и обновить HTTP -соединение в веб -сокет, чтобы быть совместимым с существующими правилами брандмауэра.

Answer 2

Вообще говоря, вы должны ожидать использования веб -питания с пользовательскими реализациями сервера, предназначенными для обработки нагрузки легким образом. Такие серверы уже существуют для долгоживущих соединений кометы и тому подобного.

Answer 3

Он отличается от HTTP тем, что каждый последующий запрос / ответ не должен быть завершен в HTTP -сообщении с заголовками HTTP. Таким образом, приложения в реальном времени не понадобятся накладные расходы на заголовки. После первоначального рукопожатия HTTP он в основном ведет себя как обычный сокет TCP.

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

Answer 4

Взгляните на веб -питания HTML 5, реализованные в Tornado Webserver:http://bret.appspot.com/entry/web-sockets-in-tornado

Я еще не играл с этим модулем.