Я работаю над программным обеспечением с открытым исходным кодом для многоагентных систем, и недавно нам пришлось создать транспортную опцию на основе UDP для использования p2p через сети 4G/3G. Мы протестировали это в планах данных T Mobile, а также в различных академических сетях за NAT, и я чувствую себя довольно уверенно в реализации на данный момент. Поскольку здесь нет никаких твердых решений по этому вопросу, я подумал, что хотел бы поделиться тем типом решения, которое мы в настоящее время реализовали в промежуточном программном обеспечении MADARA (http://madara.sourceforge.net/), с помощью опции транспорта REGISTRY_CLIENT.
Для нас мы выбрали то, что вы можете назвать сервисом реестра или службой имен (если вы знакомы с CORBA) для конечных точек P2P. Серверу реестра необходимо запустить на каком-то общедоступном ip-порту, который UDP может достигать в одностороннем сообщении. Для наших тестов мы арендовали узел Amazon EC2 и убедились, что настройки брандмауэра разрешили UDP-трафик через порт UDP, к которому мы собирались привязываться. На стороне сервера (общедоступный ip: порт для сервера реестра) мы привязываемся к порту и ожидаем регистрации клиентов. Любая P2P-клиент, который хочет поговорить с другим посылает сообщение реестра в реестре сервер
P2P client ----> [register message] ---> Registry Server
Сообщение регистра может иметь любое произвольное содержимое. На самом деле у нас нет содержимого, кроме заголовка сообщения, из нашего обычного протокола данных. На стороне сервера мы проверяем удаленный хост отправителя сообщения регистра (клиент P2P в левом верхнем углу) через обычные вызовы recc сокета. Этот удаленный хост должен быть информацией о конечных точках через брандмауэр, который защищает клиент P2P.
Чтобы понять, что происходит здесь, мы должны посмотреть, как сообщения направляются для клиента P2P на наш публичный сервер реестра. На следующей диаграмме ASCII показана удаленная информация, которую может видеть сокет (например, сопоставление брандмауэра) по пути от клиента P2P к нашему серверу EC2. Это показывает только один брандмауэр, но он должен работать с несколькими NAT между клиентом P2P и сервером реестра, если NAT поддерживают открытый ip: порты открываются, когда трафик проходит через назначенный ip: порт в этом конкретном NAT.
P2P client ----> [message from 192.168.1.10:35000] ---> Firewall ---> [message from 111.111.50.34:5627] --> Registry Server
Теперь, если мы пытались послать сообщение 192.168.1.10:35000 с нашего сервера реестра, оно не будет (или, по крайней мере, было бы почти наверняка пойти в неправильном месте). Аналогично, вы можете видеть, что брандмауэр 4G также меняет порт с 35000 на 5627. Чтобы отправить сообщение обратно клиенту P2P, вам нужно сделать две вещи: 1) отправить сообщение возврата через 111.111.50.34:5627 чем какая-либо информация ip: port, с которой мы первоначально связывались на стороне клиента P2P, и 2) убедитесь, что клиент P2P или сервер реестра повторно отправляют данные друг другу часто - один раз в секунду казалось, что для нашей цели было совершенно необходимо связать общественный ip: порт 111.111.50.34:5627, в нашем примере.
Как часть нашего протокола, мы не просто отправляем бесполезный пакет обратно зарегистрированному P2P-клиенту. Мы отправляем все соответствующие общедоступные пакеты ip: port из P2P-клиентов, которые находятся в группе/клике/домене этого клиента/независимо. В принципе, мы отправляем информацию об обнаружении клиента P2P для всего, что известно серверу реестра, что похоже на клиент P2P.
Например, предположим, что два клиента P2P отправили серверу реестра через 111.111.50.34:5627 и 111.111.37.24:15234 ip: привязки портов через брандмауэр поставщика 4G. Новый P2P-клиент соединяется с 111.111.70.105:7000, и мы ответим назад с 2-х другими конечными точками в простом перечислении:
[Registry Response for P2P Client #3]
111.111.50.34:5627
111.111.37.24:15234
Теперь на P2P Client # 3 конца, вы берете этот список и использовать это как потенциальные конечные точки для вашего приложения P2P. Это ваши сверстники P2P. Вы можете создавать пакеты UDP для них через тот же сокет, который вы зарегистрировали, и пока они не отстают от консервативных брандмауэров (таких как мобильные привязанные точки доступа на вашем телефоне, которые по моему опыту традиционно предназначены для блокировки всего входящего трафика UDP на эфемерном порту привязки без настроек конфигурации, доступных для включения переадресации портов), и трафик должен иметь возможность протекать в обоих направлениях.
Как уже отмечалось ранее, чтобы поддерживать правильные соединения P2P UDP, вам просто нужно периодически пересылать данные в/из этой конечной точки, чтобы поддерживать общедоступный ip: port binding активным и активным на каждом брандмауэре, защищающем клиенты P2P. Это может быть сделано путем периодической пересылки регистрационной информации на сервер публичного реестра и/или приема UDP-пакетов от других клиентов P2P к этому общедоступному ip-порту, который брандмауэр 4G выделил вашему клиенту P2P.
Да, они есть! Посмотрите на мой ответ! Я взял две ссылки на мой ответ с этой страницы в Википедии !!! –
Nevermind. Техника университета Васеда может работать для некоторых симметричных маршрутизаторов меньшего масштаба (я сам их не видел), но я сам реализовал его, и он НЕ работает для сетей 3/4G. –