Здравствуйте! Хочу посоветоваться по поводу написания многопоточного порт-маппеда. Существует ТЗ вобщем-то из него и исхожу. Готовых вариантов подходящих под ТЗ не нашел (может кто подскажет?) потому пишу сам.
ТЗ:
Создать порт-маппед приложение (серверная часть), для защиты трафика основного сервера путем шифрования. Информация о нагрузке:
- Среднее количество клиентов 1000, пиковая нагрузка 5000.
- Среднее время подключения клиента 5 часов.
- Объем трафика за время сессии ~10 мегабайт.
- Пакеты размером от 4 байт до 2 килобайт.
- Среднее количество пакетов в минуту ~500.

Вобщем-то сам вопрос состоит в том, каким алгоритмом реализовывать приложение. От Indy и подобных компонентов отказался сразу. Писать буду используя WinSock API. От выделения на каждого клиента отдельного потока отказался сразу, ввиду большого количества клиентов и большой продолжительности сессии. Остановился на варианте создания пула потоков (50-100 потоков) и на них распределить нагрузку путем выбора select'ом сокетов с которых необходимо получить данные. Алгоритм примерно такой: 1 поток отводим для обработки подключений клиентов, 1 поток отводим для вызова select'ов, после получения списка сокетов требующих обработки, распределять те самые сокеты по пулу. В случае если все потоки в пуле заняты, ставить сокеты в очередь для обработки.
Готов выслушать критику относительно алгоритма. Возможно кто-то подскажет более действенное решение.

Почитай про порты завершения ввода/вывода (I/O Completion Ports). Хорошо описаны у Рихтера и Кларка в книге "Программирование серверных приложений для Microsoft Windows 2000", а так же описаны в книге "Программирование в сетях Windows" у Джонса и Оланда.

один поток транспортный - асинхронные WSA вызовы с CompletionRoutine
данный поток получает данные, кладет их в очередь на обработку, мониторит очередь на отправку, отправляет

пул рабочих потоков
мониторит очередь на обработку, обрабатывает, кладет в очередь на отправку.
его лучше организовать через compleation ports (см. Вариант   (10.04.11 11:29) [1] )
при этом число рабочих потоков не будет привышать колво процессоров (ниток) x2