Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Точно, просыпайтесь, весна пришла! -)) 28.04.07 11:17 Число просмотров: 1754
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 28.04.07 12:02 Количество правок: 1
|
> В нормальных ДНС серверах есть механизм обновления.
Есть. Он называется "поллинг", и реализован в виде time to live записей. DNS сервера обновляют информацию по времени этого ttl, и то, если кто-то запросит данные по этому хосту, и запись устарела. Если сервак каждый раз будет стучаться в корневые сервера, ту-то им смерть и наступит -)) И корневые сервера никак не оповещают нижестоящих об изменениях в своих записях, ибо если они начнут это делать -- их снова массовая смерть стережёт -))
> В предлагаемом варианте его НЕТ (в противном счае это нат и
> днс отдельно, поднятые на одном хосте, или мы ходим каждый
> раз наверх, что отменяет слово "кеширующий")
Ну и чем поллинг провайдера лучше поллинга встроенного сервера? Чуть больше будет период обновления. Чуть. И всё. Можно даже не смотреть ttl отдельных записей, а тупо делать их инвалидными через час. Или два. От этого достоверность данных DNS не сильно пострадает, если по-умолчанию ttl рекомендуют выставлять 3 часа вроде -))
> достоверность данных такой поделухи относительно
> регулярного DNS сервера объективно ниже.
Конечно, если настроишь на шлюзе кэширующий DNS сервер с гордым брэндом ISC "от производителя", то доверие к ней выше. Субъективно выше ;-) А поллить она будет всё также.
> А если так, то что? Шифруем на уровне приложений - значит
> контрольная сумма считается от "правильных" данных.
> Во всех книгах написано и жизнь показывает, что
> СОВОКУПНОСТЬ ХОСТ\ПОРТ ЯВЛЯЕТСЯ НЕОТЪЕМЛЕМОЙ ЧАСТЬЮ UDP
> ДАТАГРАММЫ! Это к вопросу о красавчегах.
Цитирую http://ru.wikipedia.org/wiki/UDP
"Заголовок UDP содержит 4 поля, 2 из которых («порт отправителя» и «контрольная сумма») опциональны".
Такой пакет не будет обрублен ни одним маршрутизатором, и он успешно дойдёт до хоста в инете, потому что он соответствует стандарту. Но вот как его натить ОБРАТНО? -))
> UDP - протокол транспортного уровня, причём тут уровень
> приложений?
Потому что голый UDP нафиг не нужен, кроме как для потокового аудио видео и проч, где можно терять пакеты и не требовать их повторной доставки... хотя само слово "поток" навевает на размышления -)) И разработчики софта начинают извращаться, затачивая его под себя, и придумывают ТАКОЕ! -)))))))))
> Если слать ответ на порт yyyy, никак не фигурирующий в
> исходной посылке, на клиентской тачке надо поднимать
> _серверный сокет_, слушающий этот самый yyyy.
Даже если вы сформируете "правильный" пакет, который говорит "порт отправителя такой-то", и сервер вам "правильно" ответит на этот порт (что не обязан, в принципе делать, это всё на усмотрение программиста на "той" стороне), это не отменяет вашей программе слушать сокет на "правильном" порту, иначе кому его доставлять операционной системе, получившей такой пакет? Другое дело, что один и тот же UDP порт могут слушать НЕСКОЛЬКО сокетов разных программ, и ось будет исправно копировать датаграммы в каждый сокет, что невозможно при TCP, там только один слушатель порта.
Далее. Предположим вы формируете "правильные" пакеты. Каким вы выберите порт отправителя? Каким его выбрать такой же программе, но на другой машине во внутренней сети и как им работать одновременно c одним и тем же сервером в интернете? Выбрать случайный порт? Тогда существует вероятность 1/65535, что они выберут один порт, и нат будет в прострации, как перенаправлять пакеты "обратно". Это достаточно серьёзная вероятность в компьютинге, NAT не будет это делать, если его создатели не разпиздяи -)
< Собсно в
> аське этот механизм есть, юзается для p2p коннектов. Как я
> понял, исходная задача этого не требовала.
У многих работает передача файлов в аське за NAT'ом?
|
|
|
подробно о проекте
Анализ криптографических сетевых...
