информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
TCP не панацея. 27.04.07 11:07  Число просмотров: 1761
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Насколько я понимаю сам TCP, теоретически нельзя посадить
> на один IP больше ~64К открытых соединений.... Венда ещё и
> рубит это в 2 раза... Печально...

TCP не панацея.
Я по аналогии с аськой, суть которой пейджинг, подумал о подобных серваках, к которым тоже могут обращатся не 32к, а милионы компов интернета в легкую, это DNS.
По UDP протоколу работать с огромным количеством компов будет проще.

> Т.е. как вариант, слушать на разных IP разными

Этот вариант не прокатит, поскольку удвоение количества АйПишных адресов на прослушке увеличивает в двое количество возможных клиентов. Стало быть чтоб могли подключиться 32 милиона клиентов, надо иметь и сообщить каждому клиенту тысячу адресов и клиент должен тысячу раз пытаться сконнкетиться, если до него уже сконнектилось около 30 милионов клиентов.

> процессами... Которые уже общаются с многопользовательской
> БД... Нда, классика... Интересно, как такие проблемы
> решаются у других -- серверами ICQ или Jabber, к примеру?

Я думаю, что клиенты могут реконнектится, если коннекшн устаревает и рвется со стороны сервера.
<programming>
Какие есть теоретические и практические ограничения в кол-ве обслуживаемых клиентов для серверного 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
<"чистая" ссылка> <обсуждение закрыто>
Получилось чего-нить с библиотекой? 28.04.07 11:30  
Автор: IgorR <Igor Razin> Статус: Member
<"чистая" ссылка> <обсуждение закрыто>
Я отвечу попозже в личку, дистрибутив скачал, справку почитал... 28.04.07 13:26  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
А че в личку? Мне тоже интересно :) 28.04.07 13:49  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Ё маё, там уже мои детали, скачай либу, посмотри, и общайся интересно с человеком -)) 28.04.07 13:53  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
Сам недавно задавался этим вопросом. В принципе упереться... 26.04.07 17:09  
Автор: tatar_0x4e Статус: Member
<"чистая" ссылка> <обсуждение закрыто>
Сам недавно задавался этим вопросом. В принципе упереться можно либо в количество сокетов, либо в количество потоков, если тупо создавать thread на каждое соединение. Судя по описанию у тебя более продвинутый сервер, так что упереться можно только в количество открываемых сокетов. См. сюда:

http://support.microsoft.com/kb/111855


Какая бяка... ~32K на процесс... Как с этим бороться? 26.04.07 17:51  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
Насколько я понимаю сам 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, когда внедрится...

> > Ну нам пока до миллионов далеко, на самом деле винда может,
> > как тут уже сказали, ажно сотни тысяч, нам пока достаточно.
>
> Точно? Откуда сотня то взялась?
http://bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=2&m=143006

> > пусть долбятся на случайное 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
<"чистая" ссылка> <обсуждение закрыто>
2 из 3 пакетов в этом случае паразиты. Остаётся умножить на число клиентов. 28.04.07 12:43  
Автор: Ustin <Ustin> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Да, я не подумал про других, борьба идёт за каждый пакет, возможно сделаю координатор подключений. 28.04.07 16:16  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 28.04.07 17:30  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
1  |  2  |  3 >>  »  






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach