Нужно приложение под win, способное держать такое количество клиентов.
Клиенты посылают в основном небольшие пакеты, не более 10 в сек. Большинство пакетов (99%) обрабатываются быстро, но небольшая часть требует обращения к sql. Производительность "sql"-части особорой роли не играет, т.е. эти запросы второстепенные, по идее можно сделать 1 поток под все такие запросы и приоритет пониже поставить.
Опыт написания под сокеты — только на уровне обучения, на простых примерах, типа echo-сервера.
В какую сторону начинать копать? Пока из прочитанного понял, что IOCP + пул потоков на обработку "быстрых" запросов, поток на "медленные". Может дадите ссылки на примеры кода/литературу? А может я не в том направлении собираюсь двигаться?

Здравствуйте, _ilya_, Вы писали:

__>Нужно приложение под win, способное держать такое количество клиентов.
__> ...
__>В какую сторону начинать копать? Пока из прочитанного понял, что IOCP + пул потоков на обработку "быстрых" запросов, поток на "медленные". Может дадите ссылки на примеры кода/литературу? А может я не в том направлении собираюсь двигаться?

Мм.. У меня положим сервер должен на каждые запрос клиента выплюнуть кое-что из базы(select-only), потому я при старте просто тупо в хеши различные все данные вытягиваю и более к базе не обращаюсь. Все это дело отоваривает 11к коннектов не напрягаясь(freebsd+kevent);

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

Что касается сокетов — 1000 коннектов то вообще не проблема, по крайней мере 6 сотен удавалось даже селектом разрулить не напрягаясь.

Здравствуйте, _ilya_, Вы писали:

__>В какую сторону начинать копать? Пока из прочитанного понял, что IOCP + пул потоков на обработку "быстрых" запросов, поток на "медленные". Может дадите ссылки на примеры кода/литературу? А может я не в том направлении собираюсь двигаться?

Делай всё на IOCP и не заморачивайся.

Здравствуйте, _ilya_, Вы писали:

__>Пока из прочитанного понял, что IOCP + пул потоков на обработку "быстрых" запросов, поток на "медленные".

Я именно так бы и делал. Примеров на вскидку не вспомню, но в своё время я легко нагуглил кучу вполне нормальных примеров.

От себя могу добавить такой пародоксальный факт. Даже в отсутствие разделяемых данных стабильней, а главное быстрей, у меня работал IOCP с одним потоком в пуле. Несколько тысяч подключений держались нормально, впрочем интенсивность сообщений была всё-таки значительно меньше 10 в секунду.
С несколькими потоками есть ещё одна засада, IOCP как-то хитро оптимизирует смену потоков, что не гарантируется порядок принятых/отправленных сообщений.

Здравствуйте, frogkiller, Вы писали:

F>Здравствуйте, _ilya_, Вы писали:

F>С несколькими потоками есть ещё одна засада, IOCP как-то хитро оптимизирует смену потоков, что не гарантируется порядок принятых/отправленных сообщений.

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

Здравствуйте, <Аноним>, Вы писали:

F>>С несколькими потоками есть ещё одна засада, IOCP как-то хитро оптимизирует смену потоков, что не гарантируется порядок принятых/отправленных сообщений.
А>Мои наблюдения показали, что если пакет от клиента обрабатывается на одном потоке и в это время приходит еще один пакет (от того же клиента), то он не будет послан на свободный поток, а дождется завершения первого, а после система пошлет его на поток какой ей вздумается.

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

А>Поясни что имеешь в виду?

Я имел ввиду, что IOCP старается по минимуму переключать контексты потоков.
Что-то типа:

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

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

Здравствуйте, frogkiller, Вы писали:

F>Здравствуйте, <Аноним>, Вы писали:

F>Это у тебя, похоже, что-то с синхронизацией не в порядке. Какие-нибудь критические секции или мьютексы блокируют весь обработчик, а надо только пошаренные данные.

Нет с синхронизацией все ок.

Я просто говорю, что:
1. если клиент отослал пакеты п1, п2, п3, то они поступят в обработчик в том же порядке или будут сгруппированы, но порядок байт не изменится, т.е. не может быть ситуации, что п2 поступит перед п1.

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

F>Пусть есть два потока. Один занят обработкой сообщения. Приходит новое сообщение, оно "передаётся" свободному потоку, который пока ждёт своей очереди. Тут приходит ещё одно сообщение (его нужно направить первомоу потоку), и обработчик самого первого как раз завершился. Переключения потоков не происходит, и третье сообщение начинает обрабатываться раньше второго.

F>Подобные ситуации несколько раз встречались в моей практике при значительной нагрузке.

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

Здравствуйте, <Аноним>, Вы писали:

А>Я просто говорю, что:
А>1. если клиент отослал пакеты п1, п2, п3, то они поступят в обработчик в том же порядке или будут сгруппированы, но порядок байт не изменится, т.е. не может быть ситуации, что п2 поступит перед п1.

А>2. если имеется два треда т1 и т2, на т1 обрабатывается пакет п1, а т2 свободный, и в это время поступит пакет п2(п1 и п2 от одного клиента). Система не отправит п2 на свободный т2, а дождется завершения обработки п1 и после этого отправит п2 хоть на т1, хоть на т2, как сама решит.
А>Т.е. не могут два пакета от одного клиента обрабатываться на разных потоках одновременно, тут система синхронизацию берет на себя.

Понял. Очень может быть, что так оно и есть.

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



Есть ещё одна забавная штука. Один раз я сделал тестовый эхо-сервер. Клиент посылал нумерованные пакеты, в нотификации об отправке записывал id пакетов в set. В обработчике получения ответа, соответственно, удалял. При этом в пуле IOCP был один поток, поэтому синхронизации типа critical section не требовалось, гарантированно работа с set'ом велась только в одном единственном потоке. Из миллиона пакетов, как оказалось, пара сотен потерялась. По логу сервера — все пакеты получены и отправлены, по логу клиента — тоже самое! (Логи в отдельном потоке — тормоза минимальны) Оказалось, что что эхо-ответ приходил и обрабатывался раньше, чем приходила нотификация о записи в сокет. Это подтвердилось заведением двух set'ов — отдельно на отправление и приём.
Как такое получилось — не понимаю. Но факт.

Здравствуйте, Аноним, Вы писали:

А>2. если имеется два треда т1 и т2, на т1 обрабатывается пакет п1, а т2 свободный, и в это время поступит пакет п2(п1 и п2 от одного клиента). Система не отправит п2 на свободный т2, а дождется завершения обработки п1 и после этого отправит п2 хоть на т1, хоть на т2, как сама решит.
А>Т.е. не могут два пакета от одного клиента обрабатываться на разных потоках одновременно, тут система синхронизацию берет на себя.

Ерунда. У тебя в коде что-то не так.

Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>2. если имеется два треда т1 и т2, на т1 обрабатывается пакет п1, а т2 свободный, и в это время поступит пакет п2(п1 и п2 от одного клиента). Система не отправит п2 на свободный т2, а дождется завершения обработки п1 и после этого отправит п2 хоть на т1, хоть на т2, как сама решит.
А>>Т.е. не могут два пакета от одного клиента обрабатываться на разных потоках одновременно, тут система синхронизацию берет на себя.

G>Ерунда. У тебя в коде что-то не так.
Интересно что?
А как же тогда ведет себя IOCP?
т.е. надо самому ловить пакеты на всех тредах и склеивать их??? это за нас уже делает tcp.

нет ты не прав.

Здравствуйте, Аноним, Вы писали:

G>>Ерунда. У тебя в коде что-то не так.
А>Интересно что?
Покажи код, скажу ;)

А>А как же тогда ведет себя IOCP?
А>т.е. надо самому ловить пакеты на всех тредах и склеивать их??? это за нас уже делает tcp.
IOCP ведет себя правильно, и так, как ты ему скажешь. Скажешь получить несколько пакетов одновременно — получишь.

Здравствуйте, adontz, Вы писали:

__>>В какую сторону начинать копать? Пока из прочитанного понял, что IOCP + пул потоков на обработку "быстрых" запросов, поток на "медленные".

A>Делай всё на IOCP и не заморачивайся.

Согласен с предыдущим оратором.
Не нужно реализовывать отдельного потока для обработки "медленных" запросов, достаточно лишь увеличить количество потоков IOCP. Издержки минимальны, зато логика гораздо проще (=надежнее, =быстрее реализуемо, =меньше проблем с синхронизацией).

Здравствуйте, Аноним, Вы писали:

А>Т.е. не могут два пакета от одного клиента обрабатываться на разных потоках одновременно, тут система синхронизацию берет на себя.

IOCP получает уведомления не про поступающие пакеты, а про завершение вызванных тобой операций ввода-вывода. Я не проверял, но скорее всего если вызвать ReadFile несколько раз подряд, то несколько уведомлений и поступит, причем не исключено что в разные потоки, причем не исключено что обрабатываться они будут одновременно (т.к. системе вообще говоря пофиг понятие "обработки уведомления"). Не проверял я это потому что при этом неоправдано увеличивается сложность синхронизации, а выгоды никакой.
Ты уверен что оно тебе надо?

Здравствуйте, Michael Chelnokov, Вы писали:

MC>Я не проверял, но скорее всего если вызвать ReadFile несколько раз подряд, то несколько уведомлений и поступит, причем не исключено что в разные потоки, причем не исключено что обрабатываться они будут одновременно (т.к. системе вообще говоря пофиг понятие "обработки уведомления").
Так и есть.

Здравствуйте, Gomes, Вы писали:

MC>>если вызвать ReadFile несколько раз подряд, то несколько уведомлений и поступит
G>Так и есть.

Я окончательно проснулся и вспомнил про UDP
Да, конечно, так и есть, причем активно используется в случае UDP. Один сокет UDP привязывается к IOCP, потом сразу N потоков вызывают WSARecvFrom и болтаются в GetQueuedCompletionStatus. Каждое уведомление означает приход одной дейтаграммы, причем нас не волнует последовательность их обработки, всё прекрасно.

В случае TCP трудно придумать применение, т.к. никогда изначально неизвестно сколько байт вернет один конкретный вызов Read. Один вернет X, другой Y, причем нет гарантии что Y у нас будет обработан строго после X (т.е. в порядке их поступления).

Здравствуйте, Michael Chelnokov, Вы писали:

MC>В случае TCP трудно придумать применение
Это да, не легко :)

Здравствуйте, Michael Chelnokov, Вы писали:

MC>В случае TCP трудно придумать применение, т.к. никогда изначально неизвестно сколько байт вернет один конкретный вызов Read. Один вернет X, другой Y, причем нет гарантии что Y у нас будет обработан строго после X (т.е. в порядке их поступления).

Что-то я запутался. В случае TCP, уведомления о чтении из одного и того же сокета будут приходить в порядке отправления или как попало?

Здравствуйте, lgb, Вы писали:

lgb>Что-то я запутался. В случае TCP, уведомления о чтении из одного и того же сокета будут приходить в порядке отправления или как попало?

Приходить — в порядке завершения операций чтения. Но нет никакой гарантии что сразу по выходу из GetQueuedCompletionStatus не произойдет переключения потоков.