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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Как у Микрософтовского MSDE. Вот и изобрели велосипед. 28.04.07 17:00  Число просмотров: 1437
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
<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-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach