TCP/IP и разработка сетевых приложений

Вы прочитали последнее предложение:

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

По статье сложно сказать, но под назначением я думаю имеется в виду клиент. Это не очень хорошая статья.

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

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

Как сервер, осуществляющий прослушивание конца соединения, вы можете установить параметры в прослушивающем сокете TCP/IP, чтобы ограничить количество соединений, которые будут удерживаться на уровне сокета, и решить, сколько из этих соединений вы хотите принять — это позволяют принимать 2 постоянных соединения или 4 кратковременных соединения по мере необходимости.

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

Хотя, возможно, стоит сделать шаг назад.

Если у вас есть сервер, который должен прослушивать запросы от множества клиентов, у вас может быть идеальный вариант использования архитектуры, основанной на сообщениях. Если вы используете сильно связанные соединения, подобные тем, которые создаются с помощью TCP/IP, ваши клиенты и серверы должны будут много знать друг о друге, и вам придется писать много низкоуровневого кода соединения.

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

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

Промежуточное программное обеспечение, ориентированное на обмен сообщениями, такое как Apache ActiveMQ и Weblogic, предлагает API, которые вы можете использовать из C++ для управления и использования очередей и других объектов обмена сообщениями. ActiveMQ имеет открытый исходный код, а Weblogic продается Oracle (который купил BEA). Есть много других отличных серверов обмена сообщениями, поэтому используйте их в качестве примеров, чтобы начать работу, если вам кажется, что обмен сообщениями стоит изучить.

Я думаю, что ключевые слова "по месту назначения". Одиночное TCP-соединение пытается ускориться до доступной пропускной способности. Поэтому, если вы разрешаете больше подключений к одному и тому же месту назначения, они должны использовать одну и ту же пропускную способность.

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

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

(извините, я пока не могу размещать гиперссылки) здесь msdn.microsoft.com/en-us/library/ms738559%28VS.85%29.aspx вы можете увидеть, что такое низкая производительность.

здесь msdn.microsoft.com/en-us/magazine/cc300760.aspx является примером многопоточного сервера, который работает достаточно хорошо.

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

Например, SMTP работает аналогичным образом. Когда соединений слишком много, он возвращает код 4xx и закрывает ваше соединение.

Также см. этот вопрос: Какой лучший epoll/kqueue /выберите эквивалент в Windows?