Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | | | | | | | | |
аки медведы ;) 28.04.07 10:03 Число просмотров: 1493
Автор: Ustin <Ustin> Статус: Elderman
|
> Ответы DNS серверов ВСЕГДА "вероятно недостоверны", обычно
> после смены параметров на сервере, ответственного за тот
> или иной домен, это некоторое время (часа 3) "ползёт" на
> корневые сервера, а через какое время нижележащие сервера
> "соизволят" обратится к ним -- один Бог и админы, которые
> их настраивали, ведают. Этот как свет звёзд, который летит
> к нам годы, и никто не знает, что там "на самом деле"
> происходит.
В нормальных ДНС серверах есть механизм обновления. В предлагаемом варианте его НЕТ (в противном счае это нат и днс отдельно, поднятые на одном хосте, или мы ходим каждый раз наверх, что отменяет слово "кеширующий"), => достоверность данных такой поделухи относительно регулярного DNS сервера объективно ниже.
> Гы-гы, DNS сервер провайдера — не истина в последней
> инстанции -))
Не спорю ;)
> Я не говорил того, что шифруем ПОЛЯ пакета, там речь идёт
> не о полях, а о пользовательской части данных датаграммы.
А если так, то что? Шифруем на уровне приложений - значит контрольная сумма считается от "правильных" данных.
Во всех книгах написано и жизнь показывает, что СОВОКУПНОСТЬ ХОСТ\ПОРТ ЯВЛЯЕТСЯ НЕОТЪЕМЛЕМОЙ ЧАСТЬЮ UDP ДАТАГРАММЫ! Это к вопросу о красавчегах.
> > Шлюз с натом не при делах, как я себе
> > понимаю, только потому что после подмены не удаётся
> > расшифровать данные.
> Нет, он остаётся ни при делах только потому, что не знает
> КОМУ во внутренней сету доставить данные ОБРАТНО, потому
> что в UDP не заложен механизм "обратно", его реализуют на
> уровне приложений программеры. Со своими собственными
> жирными тараканами в бошках -))
NAT aka Network adress translation является механизмом трансляции сетевых адресов, одним из способов взаимодействия частной и глобальной сети. И в данные он лезет (за искл контрольных сумм) в случае трансляции ICMP датаграмм. В случае ICMP никакого "port" нет, и вот тет-то и надо применить недюжинные усилия для сохранения "прозрачности" NAT.
> Начнём с того, что A1 и B1 в заголовке UDP опциональны.
> Прикольно, да? -))
Угу, читаем ман, убиваем такой пакет как некорректный, пока он не повесил наш роутер ;)
> Очень хорошо. Но вы думаете за разработчиков. А они не
> обязаны и чаще всего не шлют обратный пакет на тот порт,
> что был указан в заголовке датаграммы, могут его не
> указывать, более того, часто там что-то вроде этого:
> "софтина пуляет серваку на порт xxxx, оно отвечает ему на
> yyyy" и всё. Кранты, наш хитрый план натченья UDP
> провалился, если мы не знаем подробностей "протокола" на
> уровне приложений.
UDP - протокол транспортного уровня, причём тут уровень приложений?
Если слать ответ на порт yyyy, никак не фигурирующий в исходной посылке, на клиентской тачке надо поднимать _серверный сокет_, слушающий этот самый yyyy. Собсно в аське этот механизм есть, юзается для p2p коннектов. Как я понял, исходная задача этого не требовала.
|
|
<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
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
