Нат - это как бы транслятор между 2 клиентами. Ему без разницы ТСП и УДП. Различия этих протоколов что при ТСП- приходит потверждиние, а при УДП-нет. Ustin - полностью прав.
Какие есть теоретические и практические ограничения в кол-ве обслуживаемых клиентов для серверного win32 приложения?26.04.07 16:06 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 26.04.07 16:07 Количество правок: 1
В общем, subj. Клиентские приложения относительно неактивны, цепляются по TCP к серверу... поддерживают соединение (так надо), похоже на ICQ по объёму трафика и активности клиентов.
Серверное приложение будет использовать столько потоков, сколько реально параллельно сможет исполнять система — ядра + HyperThreading, скажем, 2 или 4, использовать неблокирующие сокеты, события ядра и overlapped IO.
Вопрос: сколько максимум клиентов сможет обслуживаться по такой технологии?
Заранее всем огромное спасибо за ответы.
Количество входящих подключений сервера ограничиваются...27.04.07 11:09 Автор: IgorR <Igor Razin> Статус: Member
Количество входящих подключений сервера ограничиваются ресурсами системы. Я делал около 100 тысяч, дальше загибались клиенты. Если бы было больше клиентских машин - сделал бы больше. Так что по этому вопросу беспокоиться не стоит :)
Для построения сервера я бы рекомендовал библиотеку: http://prostoserver.com/rus/ Бесплатная версия подойдет для большинства применений.
По поводу того как работают крупные системы: просто много машин и распределитель нагрузки.
Спасибо за информацию, библиотеку посмотрю...27.04.07 12:59 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 27.04.07 15:28 Количество правок: 1
Сам недавно задавался этим вопросом. В принципе упереться можно либо в количество сокетов, либо в количество потоков, если тупо создавать thread на каждое соединение. Судя по описанию у тебя более продвинутый сервер, так что упереться можно только в количество открываемых сокетов. См. сюда:
Насколько я понимаю сам TCP, теоретически нельзя посадить на один IP больше ~64К открытых соединений.... Венда ещё и рубит это в 2 раза... Печально...
Т.е. как вариант, слушать на разных IP разными процессами... Которые уже общаются с многопользовательской БД... Нда, классика... Интересно, как такие проблемы решаются у других -- серверами ICQ или Jabber, к примеру? -))
TCP не панацея.27.04.07 11:07 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
> Насколько я понимаю сам TCP, теоретически нельзя посадить > на один IP больше ~64К открытых соединений.... Венда ещё и > рубит это в 2 раза... Печально...
TCP не панацея.
Я по аналогии с аськой, суть которой пейджинг, подумал о подобных серваках, к которым тоже могут обращатся не 32к, а милионы компов интернета в легкую, это DNS.
По UDP протоколу работать с огромным количеством компов будет проще.
> Т.е. как вариант, слушать на разных IP разными
Этот вариант не прокатит, поскольку удвоение количества АйПишных адресов на прослушке увеличивает в двое количество возможных клиентов. Стало быть чтоб могли подключиться 32 милиона клиентов, надо иметь и сообщить каждому клиенту тысячу адресов и клиент должен тысячу раз пытаться сконнкетиться, если до него уже сконнектилось около 30 милионов клиентов.
> процессами... Которые уже общаются с многопользовательской > БД... Нда, классика... Интересно, как такие проблемы > решаются у других -- серверами ICQ или Jabber, к примеру?
Я думаю, что клиенты могут реконнектится, если коннекшн устаревает и рвется со стороны сервера.
Компьютеры не панацея, ментальное коммуницирование рулит -))27.04.07 12:55 [Ustin] Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 27.04.07 13:05 Количество правок: 3
> TCP не панацея. > Я по аналогии с аськой, суть которой пейджинг, подумал о > подобных серваках, к которым тоже могут обращатся не 32к, а > милионы компов интернета в легкую, это DNS. > По UDP протоколу работать с огромным количеством компов > будет проще. DNS работает по UDP, TCP там вроде как для управления.
Множество клиентов сидят за NAT, и прописывание правил для прохождения UDP "обратно" часто даже для админов нетривиальная задача, особенно когда клиентов там несколько -)) А то что DNS работает за NAT, так это заслуга каждого уважающего НАТ-прокси, который ретранслирует запросы в инет.
> Этот вариант не прокатит, поскольку удвоение количества > АйПишных адресов на прослушке увеличивает в двое количество > возможных клиентов. Стало быть чтоб могли подключиться 32 > милиона клиентов, надо иметь и сообщить каждому клиенту > тысячу адресов и клиент должен тысячу раз пытаться > сконнкетиться, если до него уже сконнектилось около 30 > милионов клиентов. Ну нам пока до миллионов далеко, на самом деле винда может, как тут уже сказали, ажно сотни тысяч, нам пока достаточно. В принципе, я понимаю, из-за чего потом начинаются тормоза, видимо в драйвере TCP нету "заточки" под такое кол-во соединений, и поиск по мегабайтным массивам становится затруднительным по времени. Про масштабирование всё ясно -- потом можно будет разнести по нескольким машинам, что крупными службами так и делается, а коннекшн перенаправлять на другой IP или неким отдельным connection manager'ом, или пусть долбятся на случайное DNS имя, типа host24.service.com или host09.service.com, а соотв. указатели на IP прописать в DNS домена service.com.
Один из вариантов- пойти по тому же пути: работаем через...27.04.07 17:34 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
> -)) А то что DNS работает за NAT, так это заслуга каждого > уважающего НАТ-прокси, который ретранслирует запросы в > инет.
Один из вариантов- пойти по тому же пути: работаем через УДП, заставляем писателей НАТ-проксей подкрутить софт и под этот протокол.
Бред, конечно, но я ведь о задаче ничего не знаю, вдруг прокатит :-).
Может почитать про IPv6, вдруг там разрядность подняли до 32 бит.
> Ну нам пока до миллионов далеко, на самом деле винда может, > как тут уже сказали, ажно сотни тысяч, нам пока достаточно.
Точно? Откуда сотня то взялась?
> крупными службами так и делается, а коннекшн перенаправлять > на другой IP или неким отдельным connection manager'ом, или > пусть долбятся на случайное DNS имя, типа > host24.service.com или host09.service.com, а соотв. > указатели на IP прописать в DNS домена service.com.
Нет, это в самом клиенте надо писать. Точнее в сам протокол внедрять. Сначала клиент ненадолго коннектится к какому-то агенту ("Distributed Transaction Coordinator"), а тот в зависимости от загрузки каналов/серваков (уж об этом то он знает) и говорит, к кому коннектится надо и клиент бросает координатора и коннектится уже на постоянку к тому, к кому надо. А дальше - как душе угодно: в зависимости от базы/логина/загрузки/чего-нибудь-еще можно на другой сервак послать, можно на другой АйПи или другой сетевой адаптер этого же сервака.
Не хочу я с UDP изобретать велосипед в виде TCP, но своего, аська с жаббером мудрее, и они на поточных протоколах.27.04.07 17:54 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 27.04.07 18:05 Количество правок: 1
> Один из вариантов- пойти по тому же пути: работаем через > УДП, заставляем писателей НАТ-проксей подкрутить софт и под > этот протокол. > Бред, конечно, но я ведь о задаче ничего не знаю, вдруг > прокатит :-). Проще бороться со своими серваками, чем с армией чужих трансляторов NAT -))
> Может почитать про IPv6, вдруг там разрядность подняли до > 32 бит. С IPv6 всё хорошо, особенно в плане TCP, там даже NAT для TCP не нужен. Чем он меня и чудесно устроит, лет так через 5-10, когда внедрится...
> > пусть долбятся на случайное DNS имя, типа > > host24.service.com или host09.service.com, а соотв. > > указатели на IP прописать в DNS домена service.com. > Нет, это в самом клиенте надо писать. Точнее в сам протокол > внедрять. Сначала клиент ненадолго коннектится к какому-то > агенту ("Distributed Transaction Coordinator"), а тот в > зависимости от загрузки каналов/серваков (уж об этом то он > знает) и говорит, к кому коннектится надо и клиент бросает > координатора и коннектится уже на постоянку к тому, к кому > надо. А дальше - как душе угодно: в зависимости от > базы/логина/загрузки/чего-нибудь-еще можно на другой сервак > послать, можно на другой АйПи или другой сетевой адаптер > этого же сервака. Это сложнее и почти так же эффективно, когда имеется пул DNS и грамотный клиентский алгоритм работы с ним.
Можно ещё внедрить round-robin DNS как на кейсерверах DNetа - идём на DNS, который отдаёт нам наименее загруженный сервак - способ учёта загруженности может быть как "от числа запросов к серваку" так и "от числа обратившихся клиентов"28.04.07 09:18 Автор: Ustin <Ustin> Статус: Elderman Отредактировано 28.04.07 09:18 Количество правок: 1
Проще клиенту параллельно требовать, скажем, 3 подключения на 3 разных сервака, кто первый ответил -- того и тапки -)) Само то, что он ответил первый, уже достаточно оптимистично.28.04.07 11:24 Автор: HandleX <Александр М.> Статус: The Elderman
3 ничем не обосновано, для достижения надёжности round-robin надо брать все. Тогда появится гора паразитного трафика и паразитной нагрузки на ВСЕ сервера, число полезных пакетов = 100/(n-1)%, +немасштабитуемо: клиент должен знать все серваки.28.04.07 12:05 Автор: Ustin <Ustin> Статус: Elderman Отредактировано 28.04.07 12:07 Количество правок: 1
Ну, если серверов всего 3, а больше и не будет, (ИМХО), то ничего страшного не случится, "паразитная нагрузка" только при подключении.28.04.07 12:24 Автор: HandleX <Александр М.> Статус: The Elderman
Ну, если серверов всего 3, а больше и не будет, (ИМХО), то ничего страшного не случится, "паразитная нагрузка" только при подключении, тут-то они и "проверятся" на нагруженность.28.04.07 12:26 Автор: HandleX <Александр М.> Статус: The Elderman
Да, я не подумал про других, борьба идёт за каждый пакет, возможно сделаю координатор подключений.28.04.07 16:16 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 28.04.07 17:30 Количество правок: 1
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
