-
Здравствуйте уважаемые! Предисловие. Server - удаленный udp server. client - клиент UDP client отправляет Server-у пакет UDP через компонент WSocket из набора библиотек ICS от overbyte.be Server принимает пакет и отправляет ответный UDP пакет client-у. client успешно получает. Но если отправлять UDP пакеты с любой другой програмки (например UDP чата) на порт и IP, полученный Server -ом, то client не получает эти пакеты. Почему? Может есть какие то настройки у компонента WSocket на стороне client-а ? Кто пользуется этими компонентами? Подскажите пожалуйста. ------------------------ вырезка кода client-а: WSocket.Addr := '0.0.0.0';
WSocket.Port :=PortUDPServerLeader;
WSocket.Proto := 'udp';
WSocket.Listen; client отправляет пакеты: WSocket.sendto(Addr, sizeof(Addr), Smem2.memory, Smem2.Size);
-
> вырезка кода client-а:
> WSocket.Listen;
Какой к лешему Listen у клиента ?
Listen - метод, используемый сервером, а не клиентом.
-
> > вырезка кода client-а:
>
>
> > WSocket.Listen;
>
>
> Какой к лешему Listen у клиента ?
> Listen - метод, используемый сервером, а не клиентом.
у компонента WSocket из ICS
прием обратных пакетов осуществляется методом Listen.
Если его убрать, то прием пакетов станет вообще невозможным.
А как по другому?
-
> на порт и IP, полученный Server -ом
С этого момента подробнее ..
-
> > на порт и IP, полученный Server -ом
>
>
> С этого момента подробнее ..
client отправляет Server-у пакет UDP Server получает вот так: WSocketUDP.ReceiveFrom(@buffer, sizeof(buffer), From, FromLen); используя данные во From, Server может отправлять сколько угодно UDP пакетов client -у На том компьютере, где запущен Server, запустим любую програмку, которая умеет отправлять UDP пакеты. Например UDP чат. В настройках для отправки пишем IP:Port, который был извлечен из From Server -ом. И пытаем отправить пакеты. Но эти пакеты не доходят до client -а. Хотя IP:Port - действующие, внешние. Почему так?
-
> Хотя IP:Port - действующие, внешние
Не факт.
К тому же тобой никак не озвучена тема файрвола на машине, где работает программулина, на которую ты жалуешься что она не получает пакеты.
-
есть роутер d-link DSL-2440U
К нему подключено 3 компа.
На одном из компов стоит client. Как вы понимаете client находится за NAT
Server установлен на удаленном компе. К которому интернет заводится витой парой. Там тип соединения ISDN без авторизации. И в настройках сетевухи указаны IP, шлюз и DNS, который дал провайдер.
-
> client находится за NAT
И с какого же перепугу у клиента "IP:Port - действующие, внешние" ?
У клиента IP-адрес вовсе не внешний, а внутренний.
Ты же наверняка не делал никаких телодвижений на d-link-роутере для конфигурирования вирт.сервера (aka "проброс порта"), настройки файрвола, организации DMZ и тд. и т.п
-
> Но если отправлять UDP пакеты с любой другой програмки (например, UDP чата) на порт и IP, полученный Server -ом, то client не получает эти пакеты. Почему? [0]
Ответ:
> Как вы понимаете client находится за NAT [6]
Мантра:
Я узнаю, что такое NAT и как это работает.
Ключ:
Отвечать на сервере надо с того же сокета, которым принимаешь udp, тогда нат снатит, другая программа, шлющая пакеты, отвечает роутеру с другого сокета, и нат не понимает, кому эти udp предназначены.
-
> Отвечать на сервере надо с того же сокета, которым принимаешь
> udp, тогда нат снатит
И то не факт.
Он "снатит" если:
1) NAT симметричного типа (в бюджетной фирмвари от d-link он никогда не присутствует)
2) Время отклика сервера превышает таймаут ожидания отклика в NAT-подсистеме роутера, отслеживающей исходящие UDP-соединения. У разных NAT CTS он обычно находится в диапазоне 1..3 мин.
-
>
> > client находится за NAT
>
>
> И с какого же перепугу у клиента "IP:Port - действующие,
> внешние" ?
> У клиента IP-адрес вовсе не внешний, а внутренний.
>
> Ты же наверняка не делал никаких телодвижений на d-link-
> роутере для конфигурирования вирт.сервера (aka "проброс
> порта"), настройки файрвола, организации DMZ и тд. и т.п
Ну как же он внутренний Ip у client ?
Внутренний ip= 172.16.15.15
client отправляет UDP пакет на Server.
И сервер извлекает из пакета внешний IP = 178.88.22.138
-
Ребята, подскажите мне, как сделать правильно?
Чтобы client мог обходить nat
-
> И сервер извлекает из пакета внешний IP = 178.88.22.138
..и пытается отправить по этому адресу пакет, через хз сколько времени да еще поди с другого гнезда.
А у клиента-то адрес не 178.88.22.138, а 172.16.15.15 !
> Чтобы client мог обходить nat
см. [8] с учетом [9]
Либо задействовать посредника - stun-сервер.
-
> И сервер извлекает из пакета внешний IP = 178.88.22.138
Сервер извлекет, то что будет указано. UDP не так работает, как вам кажется.
-
Прочитал статью, но так и не понял, как мне организовать
связь client1, client2, client3 и т.д. с client_glavn
и как постоить STUN сервер. Назовем его Server. Он будет у нас находиться на постоянном статическом IP.
Дайте пожалуйста алгоритм. Так сказать для чайников
-
-
> xss22 (29.03.2012 10:16:14) [14]
Связь обеспечивают с client --> server и ни иначе, более того в отличии от
TCP использовать вторично сокет не получится. Соединение в UDP не делается
-
> > xss22 (29.03.2012 10:16:14) [14]
>
> Связь обеспечивают с client --> server и ни иначе, более
> того в отличии от
> TCP использовать вторично сокет не получится. Соединение
> в UDP не делается
Ну а как быть тогда?
У нас есть Server. С ним клиенты связываются по TCP.
Но также есть потребность, чтобы некоторые клиенты могли принимать UDP пакеты от других клиентов.
-
> Anatoly Podgoretsky © (29.03.12 10:29) [16]
> в отличии от TCP использовать вторично сокет не получится.
почему? если клиент отправляет серверу ещё один пакет с тем же номером локального порта, что и предыдущий, сервер вышлет ему ответный пакет на этот же порт.
-
> RWolf © (29.03.12 10:50) [18]
Да но это другой сокет, а не тот который в соединение, о чем я и говорю.
Есть два метода, когда адрес ответа передается в сообщение, например выше указаная технология STUN, и когда адрес и порт ответа содержатся с самом сокете. UDP позволяет указывать абсолютно любой адрес, не обязательно даже на компьютере с клиентом. Третья технология когда ни порт не передается, а используется по умолчанию, а адрес определяется из соединения.
-
> xss22 (29.03.2012 10:35:17) [17]
Не вижу ни каких проблем, если надо отвечать, то укажать с сокете куда, или
указать в сообщение куда, или договориться об фиксированых портах и адресах.
Сообщения принимает не клиет, а сервер.
-
> есть потребность, чтобы некоторые клиенты могли принимать
> UDP пакеты от других клиентов
> как постоить STUN сервер
Его не обязательно строить. Можно задействовать любой из публично доступных в Тырнете. А если приспичило построить его в рамках своего сервиса, то отправная точка - http://ru.wikipedia.org/wiki/STUN
-
Сокет умирает сразу после передачи! Ответить на тот же сокет не возможно.
Но никто не мешает запусить UDP Server, котрый известен одним из трех указаных способов, и принимать на нем сообщения. А на серверной стороне клиент.
-
-
> Это получается нужно 2 разных машины?
Не получается.
Достаточно одной, но с двумя внешними стат.адресами.
> На одном компе можно сделать? и в рамках одной программы
Можно, см. выше.
Зачем тебе выеживаться со своим stun'ом, если провайдер выделил тебе один адрес и платить за второй нет желания ?
Воспользуйся существующими публичными stun-сервисами.
-
А как можно обойти симметричный тип NAt ?
-
ты со своим коническим сначала разберись)
-
так в том то и дело, что у меня симметричный NAT. Отсюда то и все беды!
и как его можно обойти?
-
-
-
ну если верить этой программулине, то stun тебя не спасет.
-
> ну если верить этой программулине, то stun тебя не спасет.
да уже понял, что STUN не может обойти симметричный NAT. Какой еще есть выход?
-
Симметричный NAT - наиболее распространенный NAT.
И как же его обходить?
-
> xss22 (30.03.2012 11:49:32) [32]
За всю жизнь не сталкивался и не использовал, так что слухи о
распространение очень сильно преувеличены.
-
А никак.
Только через сервер-посредник.
В противном случае проблема решается только конфигурированием роутера - DMZ, виртуализация сервиса (aka проброс порта), UPnp
-
> слухи о распространение очень сильно преувеличены
Эт точно.
-
-
Проверить-то недолго)
Посылаешь сообщение своему серверу от клиента A (который за НАТом), сервер тебе показывает адресA:портA отправителя.
Тут же быстренько в темпе ошпаренного кота:
- посылаешь сообщение от клиента B (адресB:портB) клиенту A (адресA:портA).
Если сообщение дошло, то это конусный НАТ.
- посылаешь сообщение от клиента B (адресB:портA) клиенту A (адресA:портA).
Если сообщение дошло, то это порт-рестриктед НАТ.
Иначе это симметричный НАТ.
Иначе
-
А где можно найти готовый компонент DELPHI, работающего со STUN серверами?
-
самому состряпать-то не судьба ?
протокол ведь примитивный ..
-
> Сергей М. © (31.03.12 18:38) [39]
>
> самому состряпать-то не судьба ?
> протокол ведь примитивный ..
>
Думаю ты прав!
-
> Посылаешь сообщение своему серверу от клиента A (который
> за НАТом), сервер тебе показывает адресA:портA отправителя.
> Тут же быстренько в темпе ошпаренного кота:
> - посылаешь сообщение от клиента B (адресB:портB) клиенту
> A (адресA:портA).
> Если сообщение дошло, то это конусный НАТ.
Можно подробней по реализации? Целый день бился, ничего не работает.
У меня как оказалось Port-Restricted Cone NAT (Zyxel Keenetic)
Сделал следующее:
1. На роутере пробросил порт 5210 на компьютер
2. В приложении создал IDUDPServer на 5210 порт.
3. Положил два UDP клиента, задал порты исходящие 5211, 5212.
4. Подключаюсь к UDP серверу через Роутер, 192.168.1.1:5210
5. С каждого клиента отправляю текст '1' и '2' на сервер для определения реальных IP адресов (получаю например 192.168.1.1:4440 и 192.168.1.1:4441)
6. Кладу еще 2 UDP сервера, каждый слушает под клиентом, 5211 и 5212
7. Пытаюсь отправить пакет с Клиента1 на Клиент2 и наоборот
8. Сервера, которые слушают под клиентами не получают пакетов, NAT не пробит? Почему?
Помогите пожалуйста разобраться, сил уже нет
P.S. Если Клиент1 отправляет пакет не на IP роутера, а на IP самой машины (и порт 5211 или 5212), то все работает. Соответственно пакеты рубятся на роутере. Или ... ?
-
Зачем НАТ в локалке (4).
Порт на файрволе рутера разрешен?
Что показывает нетстат? на данном интерфейсе рутера, на машине приемника?
-
Удалено модератором
-
> Зачем НАТ в локалке (4).
Скорее всего из-за этого проблема, что оба пира находятся в одной сети. Проверю на разных сетях потом буду задавать вопросы.
Спасибо за ответ, натолкнул на мысль
|
Есть новые 
Нет новых [134435 +14][b:0][p:0.001]