Интересует любая правильная информация по созданию высоконагруженных (в плане количества установленных одновременно соединений от 1000 до сотен тысяч в перспективе) TCP серверов, скорее всего с уклоном на I/O Completion Ports.
Понимаю, что есть гугл, но хотелось бы получить правильную информацию о том, куда копать и что читать от людей, которые сталкивались с этой темой. Примеры, даже простенькие, тоже не будут лишними ;-)

Спасибо.

сотни тысяч одновременных соединений?

такое вроде не делается на тсп сервере.

такое делается на тсп серверах. кластеры там всякие и карусели.

> Eraser  (03.06.2010 16:13:00)  [0]

Копай в сторону дата центров.

> [1] Медвежонок Пятачок ©   (03.06.10 16:18)

пока от тысячи до десятков тысяч.

> [2] Anatoly Podgoretsky ©   (03.06.10 16:24)

само собой, но меня больше софтовая часть сейчас интересует.

Это очень сложно. Но если количество одновременных подключений не больше 32 000, то подобное можно сделать на ICS - есть подтверждение этому. Но это все равно очень сложно, программа должна быть очень, очень четко написано. Ошибки там уже не прощаются.

> [5] Anatoly Podgoretsky ©   (03.06.10 20:10)

сейчас активно изучаю вопрос, вроде бы, если речь идет о десятках тысяч соединений (тем более, что, в моем случае, работа будет вестись менее чем с 1% соединений, остальные будут просто поддерживать связь), то можно отбиться легкой артилерий в лице одного сервера. все таки рекомендуют I/O Completion Ports, а ICS, на сколько помню, просто на обычных асинхронных сокетах построен.

> Но это все равно очень сложно, программа должна быть очень,
> очень четко написано. Ошибки там уже не прощаются.

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

ем более, что, в моем случае, работа будет вестись менее чем с 1% соединений, остальные будут просто поддерживать связь

я в таком случае отказался бы от "голого" тсп и перешел бы к http.
украл-выпил-в тюрьму.
в смысле пришел - получил - отвалил.

> [8] Медвежонок Пятачок ©   (04.06.10 01:00)


> в смысле пришел - получил - отвалил.

не подходит, в моем случае нужно все время ожидать получения.

все подходит.
жди себе на здоровье.

не подходит, в моем случае нужно все время ожидать получения.

Ежели имеется ввиду, что это клиент должен постоянно ждать управляющих команд сервера, то это другое дело.
Это просто прикладной протокол так у тебя спроектирован.

У меня тоже когда-то давно была похожая модель
Но я от нее отказался (правда совсем по другой причине).
Взял за основу http и убрал "многофазность" из старого прикладного протокола.

Клиент что-то захотел - сформировал запрос. Выполнил post, назад получил результат и не отнимает ресурсы сервера до следующего раза

> [11] Медвежонок Пятачок ©   (04.06.10 10:22)


> Ежели имеется ввиду, что это клиент должен постоянно ждать
> управляющих команд сервера, то это другое дело.

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

> Клиент что-то захотел - сформировал запрос. Выполнил post,
> назад получил результат и не отнимает ресурсы сервера до
> следующего раза

это не годится для моей ситуации. собственно сабж не об этом.

Так что постоянно стучаться на сервер просто не реально.

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

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

здесь никаких ресурсов не хватит при таком количестве соединений.

> [13] Медвежонок Пятачок ©   (04.06.10 14:55)


> клиенты обращаются с нему с запросами.

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

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

нет, БД вообще не при чем )

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


никак это только потому что протокол такой. и больше не почему.
у моих конкурентов тоже проекта аналогичные моему работают как у тебя и как они работали ранее у меня.

я изменил протокол и теперь мне не нужен постоянный канал.

товарищ, см. сабж.

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

> Медвежонок Пятачок ©   (04.06.10 01:00) [8]

Установление соединения требует в разы больше ресурсов, чем поддержание. Не фат что будет более эффективно.