2013-05-13 3 views
-2

мы знаем, что в процессе, количество потоков имеет предел, как около 1000.количество одновременных соединений в многопоточный TCP сервер

Если я хочу создать сервер TCP, основанный на многопоточность,

каждый поток отвечает за одно соединение.

Поскольку есть 1 процесс, количество потоков ограничено.

Тогда это означает, что количество одновременных соединений также ограничено.

Мое понимание правильно или нет?

если нет, почему?

благодаря

+0

Я не знаю, какой фиксированный предел числа номеров, которые вы предлагаете (системные ресурсы будут налагать предел, но его неположительный - точно 1000). Тем не менее, если вы хотите эффективно поддерживать очень большое количество параллельных подключений, вам следует использовать меньшее количество потоков, каждый из которых использует 'select' для ожидания любого из нескольких сокетов. – simonc

+0

То, что вы имели в виду, похоже на то, что в каждом потоке создайте int connfd [n]. а затем для i в (1, n): connfd [i] = accept(). и затем выберите (connfd [n])? есть ли исходные коды? благодаря! – user1944267

+1

Старая страница [C10K] (http://www.kegel.com/c10k.html), которую я связал, имеет обсуждение стратегий и фреймворков ввода-вывода. – Useless

ответ

0

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

Maximum number of threads per process in Linux?

Вы никогда не строить массово параллельный сервер, использующий поток для каждого соединения. Используйте select() или poll() и неблокирующие сокеты. Если вам нужно иметь более одного потока, работающего на входе (это действительно требует многого, прежде чем вы не сможете сделать это в одном процессе, и вы не должны делать блокирующие вызовы независимо), затем создайте рабочий пул, размер которого будет равен числу процессорные ядра, которые у вас есть, и использовать их для обработки, когда они становятся доступными.

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

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

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

http://en.wikipedia.org/wiki/Thread_pool_pattern

+0

что такое процессорное ядро? вы имели в виду число процессоров? то обычно это 1 или 2 – user1944267

+0

http://en.wikipedia.org/wiki/Multi-core_processor - в основном я имел в виду небольшое число вероятностей <20 – xaxxon

+0

ОК, обычно это очень мало. как 2 или четыре. так что вы имеете в виду: в каждом потоке создайте массив дескрипторов сокетов: int connfd [n]. а затем для i в (1, n): connfd [i] = accept(). и затем выберите (connfd [n])? есть ли исходные коды? – user1944267

0

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

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

+0

Самая большая причина, по которой люди используют этот подход: обычно потому, что они хотят делать блокирующие вызовы во время обработки ввода. Для низкопроизводительных систем с низким числом подключений это простой способ справиться с соединениями, не беспокоясь о том, как ничего не блокировать. Из-за блокировки, независимо от того, насколько простой процесс обработки, один поток не может обрабатывать трафик - даже если это всего лишь два соединения. – xaxxon

1

мы знаем, что в процессе, количество потоков имеет предел

Истинную

Если я хочу создать сервер TCP, основанный на многопоточность,

TCP-серверы основаны на сокетах TCP - все остальное представляет собой деталь реализации

каждый поток несет ответственность за одно соединение.

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

Поскольку есть 1 процесс, количество потоков ограничено. Тогда это означает, что количество одновременных соединений также ограничено.

Нитки - это ресурс. Все ресурсы ограничены. Сокеты также являются ограниченным ресурсом. Вопрос только в том, насколько хорошо ваш сервер масштабируется и не хватает ли ненужных лимитов.

Мое понимание правильно или нет?

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

Смежные вопросы