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

ну так не архитектуру "клиент = поток". хотя исходников апача не видел. но тупиковость архитектуры очевидна. вряд-ли они такое гэ закодили.

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

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

здесь как раз 1 поток = 1  запрос.

или я чего-то не понимаю?

все не так.
говоря об пуле потоков и asio, имеется ввиду, что пул потоков используется для обработки задач io_service`а. 
клиентов/подключений/чтений/записей, или чего бы то ни было еще, в терминах asio не существует. есть только задачи. а операции с сокетами - это процедуры формирующие задачи предназначенные для работы с сокетами.

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

запрещено использовать что-либо кроме мфк, стл и буста.

Это сообщение отредактировал(а) asmdzen - 24.5.2011, 23:00

libevent кстати, устроенна по такому же принципу. только менее абстрагирована. ибо там задачи идентифицируются по дескриптору(файловому/сокетному).
в asio же, задачей может быть что угодно. в прямом смысле.

boostcoder, получается значит не совсем асинхронно, ведь если на все потоки пула придет по команде типа Receive то они все зависнут на время, не так?

igsilya, asmdzen, касательно пула потоков и asio - вы все неверное понимаете. очень рекомендую читать доку с самого начала и до конца.
пул потоков в asio используется только для обработки задач io_service`ом. в коде, при работе с сокетами, не нужно знать о том что используется пул потоков. io_service сам распределяет задачи(в данном случае задачи для работы с сокетами) между потоками пула.

кто в лес, кто по дрова.
я говорю о чистых сокетах без использования сторонних библиотек-оберток и надстроек.

Добавлено через 5 минут и 25 секунд

так основное время работы сервера как раз и занимают операции ввода-вывода(http сервер по сути больше ничего делать и не должен) 



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

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

boostcoder, спасибо за объяснение, просто при просмотре примеров на бусте волосы дыбом встают - много новых элементов, например я никогда не использовал boost::bind, а он там постоянно мелькает )
потом надо будет объяснять что это делает в моем коде )
насколько я понял boost::asio и есть самый выгодный вариант (особенно если он сам работает с пулом )

я говорю об asio. на протяжении всей дискуссии.


от части. но очень отдаленно.

Добавлено @ 23:15
asmdzen, кстати http-proxy: http://alexott.net/ru/cpp/BoostAsioProxy.html
и еще, на libevent: http://monkey.org/~marius/pages/?page=nylon


Это сообщение отредактировал(а) boostcoder - 24.5.2011, 23:18

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

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

придется наверное все-таки писать под бустом, с мфк не канает что-то, поставил Sleep(10000) при Receive и засыпает вся прога - а я думал у них какие-то потоки есть (

"Не читал, но осуждаю" ©

Рекомендую серьезно ознакомиться с Asio. Возможно, после этого взгляд на мир будет совсем иной. А для затравки скажу: у меня однопоточный сервер (что-то типа SSL прокси и без пула потоков) может обрабатывать тысячи одновременных подключений (т.е. я проводил стресс тестирование, но обычная нагрузка порядка нескольких десятков-сотни). Причем, сильно нагруженных. Написан с использованием boost::asio.

Добавлено через 1 минуту и 3 секунды
asmdzen, тебе сказали, MFC давно труп. Использование его стоит свести к минимуму.