Сеть снабжает серверную модель обработки сокетом

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

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

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

В новом языке Go от Google используется аналогичный подход, более близкий к «Последовательному общению» Хоара, чем к модели акторов Эрланга, но имеющий много общего.

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

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

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

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

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