Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Мы говорим о разных вещах! 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'ом?
Конечно нет, никто это и не утверждает. Наоборот
> > Как я понял, исходная задача этого не требовала.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
