UDP отверстие перфорация не проходит через 3G

Question

Я пытаюсь реализовать в программном обеспечении функцию перфорации отверстий. Дело в том, что я реализую это с уже сделанным TCP-сервером для связи с Пользователями.

Вот что я до сих пор:

• "A" посылает сообщение на UDP Server "US" (порт 9333)
• "США" посылает обратно в "А" с портом (port 31000 - localport 31005)
• «A» отправляет сообщение на TCP-сервер «TS», говорящий, что он хочет подключиться к B (и передать порт 31000)
• «TS» отправляет сообщение «B» дает ему порт «A» (31000) и ip
• «B» отправляет сообщение (в порту 9333)
• «US» отправляет сообщение «B», называя его своим портом 45000 (местный порт 45005)
• «B» отправляет сообщение в «TS», давая udp-порт (45000)
• "TS" посылает сообщение "A", давая UdP порт б (45000) и ф
• "A" начать отправку UDP сообщение для IP B на порт 45000 и слушать на локальный_порт 31005
• «B «начать отправку сообщения udp на ip-адрес A на порт 31000 и прослушивать локальный порт 45005

Конечно, порты 31000, 31005, 45000 и 45005, например, при каждом новом соединении, которое изменяется порт, только 9333 является статическим.

Я знаю, что много назад и вперед, больше, чем должно быть на самом деле. Дело в том, что я обязан использовать TCP-сервер для связи с обоими пользователями, udp-сервер именно здесь, чтобы вернуть порт пользователя себе, чтобы он мог отправить его обратно на TCP-сервер.

Однако сообщения между пользователями не принимаются никакими ... У кого-нибудь есть идея, почему?

---

EDIT:

Я проверил мой маршрутизатор с http://nattest.net.in.tum.de/test.php и УДП перфорация отлично работает, так что проблема не исходит от моего маршрутизатора, но из моего протокола ...

Когда пользователи находятся за одним и тем же NAT, все работает нормально, конечно, он использует privates ip, но это означает, что код также работает, поэтому каждый из них приводит к проблеме протокола ...

---

EDIT 2:

На самом деле, я сделал это половина работы (А проблема исходит от моего кода на самом деле, а не протокол ... Я подключил 2 пользователей, один в 3G с iPhone, один за моим NAT на Wi-Fi.

Смешная (не так уж много) вещь, только один сокет мог получать и отправлять данные между обоими пользователями. (сокет, инициированный iphone). Согласно протоколу, у меня должно быть 2 хорошо соединенных сокета, я ошибаюсь?

Так что мне удалось пробить дыру в моем NAT, но на самом деле не в сотовом NAT.

Конечно, я протестировал сразу 2 iphones, подключенных в 3G. И никто не получил сообщение от другого.

Я пропустил что-то про сотовый NAT?

P.S. : Извините за обновление так много моего вопроса, но так как я не получаю ответа, я пытаюсь найти сам ...

P.S. 2: Так как мне удалось пробить дыру в моем NAT, я изменил название, добавив «на 3G»

---

EDIT 3: Я побежал тест http://nattest.net.in.tum.de/test.php снова с моим компьютером, подключенным к интернету через мой iphone-х 3G.

Вот результат:

Видимо весь УДП тест перфорации был успешным на 9-м испытания.

Более того, кажется:

UDP Binding Test (?): Конечная точка не зависит связывание, порт предсказания легко

Так что не должно быть каких-либо проблем подключения 2 сверстникам через 3G Connection (ну не так много, чем за «домашним» NAT) ... Я прав?

---

EDIT 4:

Просто, чтобы быть уверенными, я теперь отправить сообщение на два различных UDP сервера, чтобы проверить, если порт и локальный порт одинаков на 3G.

Короткий рассказ, порты (локальные и общедоступные) одинаковы при подключении на обоих серверах. поэтому тест, проведенный на EDIT 2, был правильным, udp является независимым от конечной точки, поэтому не должно быть никаких проблем с удалением отверстий, я думаю ... (по крайней мере, с моим провайдером)

Answer 1

К сожалению, на 100% способ выполнить перфорирование отверстий NAT с помощью UDP. В лучшем случае вы можете сделать некоторые догадки о том, как NAT и брандмауэры, вероятно, будут вести себя большую часть времени. Но всегда будут исключения, и они могут быть не редкими.

В этом случае, похоже, что вы используете центральный сервер, чтобы два одноранговых узла могли определить внешний порт друг друга и начать отправку данных друг на друга. Это довольно хороший алгоритм. Проблема в том, что маршрутизация внешнего порта может варьироваться в зависимости от назначения. Другими словами, если от A до B есть внешний порт 5000, нет гарантии, что от A до C также будет от 5000. Таким образом, имея запись центрального сервера, порт, который он видит, может не помочь никому подключить.

Вот несколько связанных вопросов с более подробной информацией.

• UDP Hole Punching Algorithm
• UDP Hole Punching not possible with mobile provider
• UDP hole punching host-specific failure

Answer 2

NAT вы за симметрична, или он изменяет свой исходящий номер порта, в зависимости от назначения. Отверстие отверстий через симметричный NAT требует другого метода (либо TURN, либо UDP с несколькими отверстиями). Попробуйте сделать это так: https://drive.google.com/file/d/0B1IimJ20gG0SY2NvaE4wRVVMbG8/view?usp=sharing