Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Мы говорим о разных вещах! 28.04.07 12:00 Число просмотров: 1837
Автор: Ustin <Ustin> Статус: Elderman Отредактировано 28.04.07 12:14 Количество правок: 1
|
Предлагаю субветку в нетвокинг!
> > В нормальных ДНС серверах есть механизм обновления. > Есть. Он называется "поллинг", и реализован в виде time to > live записей. DNS сервера обновляют информацию по времени > этого ttl, и то, если кто-то запросит данные по этому > > достоверность данных такой поделухи относительно > > регулярного DNS сервера объективно ниже. > Конечно, если настроишь на шлюзе кэширующий DNS сервер с > гордым брэндом ISC "от производителя", то доверие к ней > выше. Субъективно выше ;-) А поллить она будет всё также. Мы говорим о разных вещах!
Да согласен, только это будет модуль, отдельный от модуля NAT и никак в общем случае с ним не связанный.
> Цитирую http://ru.wikipedia.org/wiki/UDP > "Заголовок UDP содержит 4 поля, 2 из которых > («порт отправителя» и «контрольная сумма») > опциональны". Согласен, неправ, слишком категорично утверждал.
http://tools.ietf.org/html/rfc768:
--cut--
Source Port is an optional field, when meaningful, it indicates the port
of the sending process, and may be assumed to be the port to which a
reply should be addressed in the absence of any other information. If
not used, a value of zero is inserted.
--/cut--
Тем не менее http://ru.wikipedia.org/wiki/UDP говорит:
Порт 0 является зарезервированным, но может использоватся как порт источника, если приложение не ожидает ответных данных.
> Такой пакет не будет обрублен ни одним маршрутизатором, и > он успешно дойдёт до хоста в инете, потому что он > соответствует стандарту. Но вот как его натить? -)) Дойдёт, чем 0 не число? А может сделать отдельный обработчик для такой исключительной ситуации? Подозреваю, что так и есть ;)
> Потому что голый UDP нафиг не нужен, кроме как для > потокового аудио видео и проч, где можно терять пакеты и не > требовать их повторной доставки... хотя само слово "поток" > навевает на размышления -)) И разработчики софта начинают > извращаться, затачивая его под себя, и придумывают ТАКОЕ! > -))))))))) И опять: где? Но уже чисто из академического интереса, см p2p в аське, правда там TCP
> Даже если вы сформируете "правильный" пакет, который > говорит "порт отправителя такой-то", и сервер вам > "правильно" ответит на этот порт (что не обязан, в принципе > делать, это всё на усмотрение программиста на "той" > стороне), А кто программист той стороны в контексте данного топика?
> это не отменяет вашей программе слушать сокет на > "правильном" порту, иначе кому его доставлять операционной > системе, получившей такой пакет? Другое дело, что UDP порты > могут слушать НЕСКОЛЬКО сокетов разных программ, и ось > будет их исправно копировать в каждый сокет, что невозможно > при TCP, там только один слушатель порта. Ткните пальцем куда посмотреть на такую реализацию!
> Далее. Предположим вы формируете "правильные" пакеты. Каким > вы выберите порт отправителя? Каким его выбрать такой же > программе, но на другой машине во внутренней сети и как им > работать одновременно c одним и тем же сервером в > интернете? NAT не будет это делать, если его создатели не разпиздяи -) В порт-нате, о котором говорим, идентификация идёт по паре хост-порт, она уникальна если (p1=p2) & (h1!=h2)
> У многих работает передача файлов в аське за NAT'ом? Конечно нет, никто это и не утверждает. Наоборот
> > Как я понял, исходная задача этого не требовала.
|
|
|