Высоконагруженный TCP сервер

← →
Eraser © (2010-06-03 16:13) [0]

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

Спасибо.

← →
Медвежонок Пятачок © (2010-06-03 16:18) [1]

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

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

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

← →
Anatoly Podgoretsky © (2010-06-03 16:24) [2]

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

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

← →
Eraser © (2010-06-03 16:24) [3]

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

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

← →
Eraser © (2010-06-03 16:25) [4]

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

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

← →
Anatoly Podgoretsky © (2010-06-03 20:10) [5]

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

← →
Eraser © (2010-06-03 23:47) [6]

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

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

← →
Eraser © (2010-06-03 23:48) [7]

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

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

← →
Медвежонок Пятачок © (2010-06-04 01:00) [8]

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

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

← →
Eraser © (2010-06-04 01:40) [9]

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

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

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

← →
Медвежонок Пятачок © (2010-06-04 10:07) [10]

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

← →
Медвежонок Пятачок © (2010-06-04 10:22) [11]

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

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

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

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

← →
Eraser © (2010-06-04 14:44) [12]

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

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

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

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

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

← →
Медвежонок Пятачок © (2010-06-04 14:55) [13]

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

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

← →
Медвежонок Пятачок © (2010-06-04 14:57) [14]

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

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

← →
Eraser © (2010-06-04 15:25) [15]

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

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

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

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

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

← →
Медвежонок Пятачок © (2010-06-04 15:31) [16]

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

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

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

← →
Eraser © (2010-06-04 18:38) [17]

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

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

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

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

← →
CrytoGen (2010-06-06 19:30) [20]

http вроде бы позволяет поддерживать подключение и выполнять несколько запросов в ходе одного подключение, я так понял об этом и речь

> [20] CrytoGen (06.06.10 19:30)

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

Транспортный поток акцептует клиентов, получает запрос, кладет в очередь запросов, следит за очередью ответов, отсылает.
Рабочий поток (пул) следит за очередью запросов, обрабатывает, кладет ответ в очередь ответов.
Обмен c сокетами через WSA ф-ии с CompleationRoutine, с рабочими потоками с использрованием GetQueuedCompletionStatus, PostQueuedCompletionStatus

Примерно так

← →
Hello, Word (2010-06-16 18:02) [23]

На Торри есть компонент HPScktSrvr, юзает Completion port. Быстрей ево не встречал. На Indy сервак при 300 клинтах за 50% проц грузит, тож самое на етом компоненте дает 1-2 %
http://www.torry.net/pages.php?id=220

> [23] Hello, Word (16.06.10 18:02)

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

PS
Инди даже не рассматривался как вариант, это отличные компоненты, которые давно служат верой и правдой, но совершенно для другого сегмента ПО.

> Eraser © (16.06.10 18:34) [24]

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

Бывшим завсегдатаем этого форума написано вроде.

Высоконагруженный TCP сервер Найти похожие ветки