Какую модель на основе сокетов следует использовать для множества одновременных подключений?

Лично я бы посоветовал вам использовать дизайн на основе IOCP, но тогда я бы сказал, что, поскольку у меня есть фреймворк на основе IOCP, который я использовал в течение многих лет для разработки высокопроизводительных серверов для клиентов.

Недавно я собрал некоторые из причин, по которым предпочитаю IOCP другим моделям, доступным в Windows, и они доступны здесь, в моем блоге здесь.

Часто «сложность» приводится как причина избегать IOCP, но, честно говоря, если вы делаете что-то кроме «потока на соединение», код все равно будет достаточно сложным. У меня есть бесплатный набор кода C++ с примерами серверов, который вы Вы можете взглянуть на него, он выполняет всю работу IOCP за вас, а примеры серверов являются хорошей отправной точкой для вашего собственного кода. Вы можете получить его по адресу здесь.

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

Какую бы модель вы ни выбрали, САМАЯ важная вещь, ИМХО, заключается в том, чтобы начать тестирование производительности и нагрузки с 0 ДНЯ. Таким образом, вы ЗНАЕТЕ, сколько одновременных подключений вы можете поддерживать на целевом оборудовании, и вы можете быстро обнаружить неподходящие проектные решения. которые вызывают это падение. Параллелизм вашего сервера легко растратить. См. здесь для получения дополнительной информации.

Поскольку Джей упомянул ENet... Я обнаружил, что наш ENet-сервер на основе IOCP хорошо работает со стандартным клиентским кодом Enet. Но помните, ENet разработан как одноранговый протокол, и поэтому возникают некоторые проблемы, когда вы начинаете пытаться использовать его на сервере. Со стандартным кодом ENet у вас, по сути, есть однопоточный сетевой насос, и это просто не может сравниться с масштабируемостью, которую вы получаете от IOCP. В итоге я переписал код обработки протокола ENet с нуля, чтобы он работал с асинхронным вводом-выводом и IOCP, и это нетривиальный объем работы. В настоящее время я работаю над новой версией этого кода, в которой в качестве основы используется новейший протокол ENet, и, надеюсь, он будет доступен в начале 2011 года с полным сравнением производительности со стандартным кодом ENet, используемым в большом количестве ситуаций с одновременным подключением к серверу.

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

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

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

Затем вы можете решить, должны ли вы гарантировать порядок пакетов и насколько важен каждый отправленный пакет, поскольку тогда вам нужно будет смотреть на TPC или UDP. (http://www.skullbox.net/tcpudp.php)

Если вы хотите поддерживать 5000 клиентов, то наличие такого количества потоков может быть проблемой производительности, в зависимости от объема памяти, но, что более важно, от того, сколько у вас ядер и насколько процессор интенсивно обрабатывается, но есть вероятность, что это будет убийца производительности.

Затем вы можете посмотреть select() (http://www.lowtek.com/sockets/select.html), что позволило бы меньшему количеству потоков обрабатывать нагрузку, но если вы выполняете потоковую передачу, это может быть проблемой, поскольку выделенный поток имеет больше смысла.

Итак, как решить, что лучше, зависит от того, какой тип игры вы пишете, поскольку оба могут быть полезны в зависимости от сценария.

Вы читали эту статью?

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

Вы должны использовать IOCP и ввод-вывод сокетов (любой простой ввод-вывод) с помощью ReadFile и WriteFile.

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

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

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