Войти
ПрограммированиеФорумСеть

UDP протокол для Интернета? (проблемы NAT) (2 стр)

Страницы: 1 2 3 419 Следующая »
#15
10:06, 27 янв. 2010

CStalker,
И при чём здесь ваш последний пост? Мы немного о другом говорим.


#16
10:24, 27 янв. 2010

Ockonal
Мы говорили о NAT, и я счел нужным пояснить. Не вам :)

radiantor
При отправке UDP пакета игроку через sendto лучше использовать переменную sockaddr_in, полученную от него через recvfrom. Иначе его NAT может не пропустить.

#17
10:40, 27 янв. 2010

CStalker
Пардон

>Иначе его NAT может не пропустить.
Обойти нат не так и просто :) Я, как писал приложение, делал предположительный тест. Тупо пересылка пакетов прошла у 20% опрашиваемых :)
у 40% был левый нат, который обойти было непросто, на разных машинах приложение падало :) В остальных 40% был нат (не помню точное название), который обойти легко

#18
10:50, 27 янв. 2010

Ockonal
NATов вообще 4 разновидности :) Я одно время экспериментировал с ним, и даже писал подсказку о способе его пробивки без использования внешнего сервера, но при тесте у разных клиентов не смог преодолеть symmetric NAT. К счастью, у моего прова другой тип NAT, легко пробиваемый.

#19
10:56, 27 янв. 2010

>NATов вообще 4 разновидности :)
>>у 40% был левый нат
Я бы сказал, что не 4, больше :) В разы больше. Каждый писатель роутеров пытается придумать свой велосипед.

>symmetric NAT
Я бы сказал больше, но я забыл уже всё :) Давно тестировал

>К счастью, у моего прова другой тип NAT, легко пробиваемый.
Это, конечно, хорошо :) Но сами согласитесь, для проекта такое условие не пойдёт. У разработчиков работает и всё, что ещё нужно для счастья :)

#20
12:47, 27 янв. 2010

Для отправки UDP пакета нужно иметь IP на который этот пакет отправляется. Если ты сидишь за NAT то сможешь лишь отправить пакет на другой комп, имеющий внешний белый IP. Но ответить тебе по UDP он не сможет, за исключением сверх редких случаев, когда у провайдера в NAT настроен динамический маппинг UDP портов. Но я такого не встречал пока, а слышал лишь в теории.

#21
14:05, 27 янв. 2010

  Вот нашел какой-то пост:
" Ответ на вопрос № 55046  09-08-2009 12:19
возможно мой ответ не имеет никакого отношения к программированию, но чтоб пробиться к компу за NATом я  пробрасываю порты (Port Forvarding, Virtual Servers). зачем изобретать велосипед?
зы: я - некропостер? "

  тема вообще интересная - так понимаю, что тут имелась ввиду только одна-направленность.
А если на машине клиента установленна такая же прога - будут ли они "пробиваться" друг к другу - может все-таки кто-нибудь объяснит по подробнее с NAT-ом (что это и с чем его едят - в простых терминах - для облегчения восприятия).

P.S. NATiveFormat - "туземный" формат или формат "туземцев" ))

#22
14:24, 27 янв. 2010

>я пробрасываю порты
Заставлять пользователя пробрасывать порты?
Это один из бредовых вариантов :) Так, как в нашем случае  аудитория - геймеры.

#23
14:25, 27 янв. 2010

http://ru.wikipedia.org/wiki/NAT

#24
14:28, 27 янв. 2010

Morphia,
что с того? Дали ссылку, нужно указывать куда именно смотреть и для кого она.

#25
15:07, 27 янв. 2010

  UDP протокол как раз и нужен для создания он-лайнового мультиплеера с "клиентом" (именно по своим UNIX-о-подобным возможностям в отличие от TCP) - только вот Network Address Translation — «преобразователь сетевых адресов» - работает так:
Ockonal
> Каждый писатель роутеров пытается придумать свой велосипед.
плюс (в смысле минус) - есть моменты когда устанавливаются ограничения по работе IP с многими адресами (это видимо для обычного пользователя интернета) - PlayerToPlayer тут прокатит - наверное не зря места на серваках продают.
  UDP - нужен для веерной рассылки (пакет один - адресов много) - разработчик роутеров не может изменить базовые настройки в механизме...
Функционирование -> Механизм NAT определён в RFC 1631, RFC 3022. (ссылка выше - может поможет).

#26
15:28, 27 янв. 2010

Megabyte-Ceercop
> Но ответить тебе по UDP он не сможет,
Сможет, и отвечает. Маршрутизатор заполняет заголовок пакета нужными данными, чтобы потом идентифицировать отправителя по ответному пакету. Надо просто правильно отсылать его назад, не просто по IP, а с полным sockaddr_in пришедшего пакета.

#27
21:00, 27 янв. 2010

Интереснее стало. Вспомнил что в интернет не ходят многоадресные (мультикаст вроде) пакеты UDP. А про П2П незнаю.
Еще про НАТ где то читал, что нормальный НАТ, открывает канал для UDP пакетов на время активности и ретранслирует их пиру от сервера.
Но речь я заводил не именно про UDP, а про то как организовать обмен между сервером и клиентом имея плюсы UDP.

#28
17:51, 28 янв. 2010

Всетаки в большинстве случаев связь с использованием UDP будет работать без всяких дополнительных настроек. Тому косвенное свидетельство Скайп, который для передачи звука использует UDP, или контра, которая идет практически у всех.

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

#29
18:59, 28 янв. 2010

Damp
> есть вероятность, что на сервер могут приходить пакеты с одинаковым IP и
> портом, но от разных клиентов
че-то верится с трудом ...
предположим два клиента за NAT'ом шлют пакеты. на входе перед NAT имеем два пакета:
1) от IP1:PORT1
2) от IP2:PORT2
на выходе за NAT'ом, понятное дело, будет один адрес. Предположим, он даже поменяет порты:
1) IP_NAT:PORT3
2) IP_NAT:PORT4

но это каким криворуким надо быть, чтобы написать такой софт для NAT, чтобы он в такой ситуации сделал PORT3=PORT4 !
IMHO, если такая ситуация и возможна, то только из-за баги в софте NAT.

Страницы: 1 2 3 419 Следующая »
ПрограммированиеФорумСеть

Тема в архиве.