Архив форумов ЦИТФорума

[TepKuH]

Есть несколько компов(допустим 10) за НАТом.
Все компы юзают такую штуку как msn messager.
У всех все окей удачно конектятся к серверу, пишутся сообщения, получают сообщения.
Проблема в следующем:
ТОЛЬКО один(другие не могут) человек сидящий за НАТом может пользоватся voice messager(такая фича в этом msn messagere) причем этот voice messager использут UDP пакеты.
Мне каца что это обясняется только тем что UDP пакеты не содержат поле "отправитель" и из-за этого NATу правильно не разрулить летящие в него пакеты.
Так ли я думаю?
И можно ли это как нить пофиксить?

[xt]

Любой пакет, отправляемый каким-нить клиентом, должен содержать адрес отправителя, если конечно отправитель расчитывает получить ответ.

Вряд ли, есть какие-нить проги которые изменяют поле Source Addr (так как по дефолту, оно обычно заполнено корректно), исключение - трояны и хакерский варез. ИМХО

[TepKuH]

"Любой пакет, отправляемый каким-нить клиентом, должен содержать адрес отправителя"
UDP - пакеты не содержат этот адресс этим они и отличаются от TCP пакетов

"Вряд ли, есть какие-нить проги которые изменяют поле Source Addr "
NAT, Proxy

[DSN]

1) IP адрес отправителя и получателя находятся в загловке IP пакета, а TCP и UDP пакеты входят в состав IP. Почитай на этом сайте про IP UDP TCP протоколы, может разберешься.

2) он имел ввиду не шлюзы и прокси, а компьютер клиента, т.е. пользователя, а у пользователя это могут быть только спец программы. И вообще во всех ситуациях всегда поле отправитель заполнятся свои адресом.

3)одной из возможных проблем может быть то что с одного IP адреса не может быть более одного коннекта voice messager с сервером MSN, отсюда и аграничения.
Еще вариант, установлен кривой НАТ шлюз, некорректно работающий с UDP, но про это я не слышал пока.

Удачи.

[crash]

"UDP - пакеты не содержат этот адресс этим они и отличаются от TCP пакетов"

Контрольная сумма - 16 битное дополнение до единицы суммы дополнений UDP заголовка, данных и псевдозаголовка. Последний содержит информацию из заголовка в протоколе IP. В случае необходимости, датаграмма дополняется в конце нулевыми октетами, чтобы общее их количество стало четным.

Псевдозаголовок, который, согласно концепции, предшествует UDP заголовку, содержит адрес отправителя, адрес получателя, поле протокола и длины UDP датаграммы. Процедура вычисления контрольной суммы такая же, как и в протоколе TCP.


http://www.citforum.ru/internet/tifamily/udpspec.shtml

[TepKuH]

http://www.citforum.ru/internet/tifamily/udpspec.shtml

[crash]

а что не понятного???
ты просто не прав.. если udp и отличается от tcp то для начала тем, что tcp пакеты с гарантированной доставкой, а udp нет..
а вот адрес отправителя и получателя указывается в ip, а не tcp или udp

[TepKuH]

-

[crash]

UDP является ненадежным протоколом: он отправляет датаграммы, которые приложение пишет в IP уровень, однако не существует гарантии того, что они достигнут конечного пункта назначения. Несмотря на то, что TCP и UDP используют один и тот же сетевой уровень (IP), TCP предоставляет приложениям абсолютно другие сервисы, нежели UDP. TCP предоставляет основанный на соединении надежный сервис потока байтов
Термин "основанный на соединении" (connection-oriented) означает, что два приложения, использующие TCP (как правило, это клиент и сервер), должны установить TCP соединение друг с другом, после чего у них появляется возможность обмениваться данными. Типичная аналогия - это набор телефонного номера, ожидание ответа от удаленного абонента, когда он говорит "алло", после чего необходимо сказать, кто звонит

TCP обеспечивает свою надежность благодаря следующему:
1. Данные от приложения разбиваются на блоки определенного размера, которые будут отправлены. Это полностью отличается от UDP, в котором каждая запись, которую осуществляет приложение, генерирует IP датаграмму этого размера. Блок информации, который передается от TCP в IP, называется сегментом (segment)
2. Когда TCP посылает сегмент, он устанавливает таймер, ожидая, что с удаленного конца придет подтверждение на этот сегмент. Если подтверждение не получено по истечении времени, сегмент передается повторно
3.Когда TCP принимает данные от удаленной стороны соединения, он отправляет подтверждение. Это подтверждение не отправляется немедленно, а обычно задерживается на доли секунды
4. TCP осуществляет расчет контрольной суммы для своего заголовка и данных. Это контрольная сумма, рассчитываемая на концах соединения, целью которой является выявить любое изменение данных в процессе передачи. Если сегмент прибывает с неверной контрольной суммой, TCP отбрасывает его и подтверждение не генерируется. (Ожидается, что отправитель отработает тайм-аут и осуществит повторную передачу.)
5. Так как TCP сегменты передаются в виде IP датаграмм, а IP датаграммы могут прибывать беспорядочно, также беспорядочно могут прибывать и TCP сегменты. После получения данных TCP может по необходимости изменить их последовательность, в результате приложение получает данные в правильном порядке.
6. TCP осуществляет контроль потока данных. Каждая сторона TCP соединения имеет определенное пространство буфера. TCP на принимающей стороне позволяет удаленной стороне посылать данные только в том случае, если получатель может поместить их в буфер. Это предотвращает от переполнения буферов медленных хостов быстрыми хостами

ну и та далее

[TepKuH]

-