Я пишу пользовательскую программу p2p, которая работает на порте 4900. В некоторых случаях, когда человек стоит за маршрутизатором, этот порт недоступен из Интернета.
Существует ли автоматический способ доступа к порту из Интернета. Я не уверен, как работают другие приложения p2p.
Кто-нибудь может пролить свет на это?
P2P-связность в двух словах. Предположим, мы говорим о UDP здесь. Следующие шаги также могут применяться к TCP с некоторыми настройками.
Перечислите все локальные IP-адреса (обычно только 1). Создайте сокет UDP для определенного номера порта ** для каждого адаптера с IP-адресом.
Для каждого сокета, созданного на шаге 1, обратитесь к серверу STUN или TURN с тем же сокетом, чтобы узнать ваш внешний IP-адрес и узнать, что внутренний номер порта сопоставляет с внешним NAT (это не всегда одно и то же значение порта). То есть ваш локальный адрес 192.168.1.2:4900 может быть 128.11.12.13:8888 внешнему миру. И некоторые NAT не всегда используют одно и то же сопоставление портов при использовании одного и того же локального порта для других IP-адресов. TURN также предоставит вам "адрес реле". Вы также можете использовать UPNP для получения адреса, сопоставленного портам, с вашего маршрутизатора, если он поддерживает этот протокол.
Через службу рандеву (SIP, XMPP, мгновенное сообщение, веб-сервис, электронную почту, чашки со строками), публикуйте список кандидатов на адрес в службу или отправьте уведомление другому клиенту, который говорит: "Эй, Я хочу связаться с вами". Это сообщение содержит все "адресаты кандидатов" (пары ip и портов), собранные в шагах 1 и 2.
Удаленный клиент, получив приглашение для подключения, также выполняет шаги 1 и 2 выше. Затем отправляет свой список кандидатов по тому же каналу, на который он получил список кандидатов-приглашенных.
Шаг штамповки отверстий. Оба клиента начинают отправку тестовых сообщений через UDP другим кандидатам на другие адреса и прослушивание одних и тех же сообщений на их конце. Всякий раз, когда принимаются сообщения, возвращайте обратно адрес, с которого он пришел. В конце концов, клиенты обнаружат, что у них есть пара адресов, которые они могут надежно отправлять дейтаграммы. Как правило, одна конечная точка принимает окончательное решение о том, по какой адресу (сокетам) для связи, и протокол облегчает эту конечную точку, сообщая другой конечной точке это решение.
** - обычно лучше не полагаться на хорошо известный порт для клиентов P2P. Поскольку два клиента за одним и тем же NAT или брандмауэром вряд ли смогут использовать ваше программное обеспечение одновременно.
Вот краткое описание некоторых технологий для изучения.
STUN - это простой сервер и протокол для клиентов за NAT/маршрутом, чтобы узнать, каковы их внешние сопоставления IP и портов.
TURN - это расширение для STUN, но поддерживает ретрансляцию для сценариев подключения P2P, где брандмауэры и NAT предотвращают прямые подключения.
ICE - это набор шагов, с помощью которых STUN и TURN используются для настройки P2P-соединения. ICE является формальным протоколом для шагов 1-5 выше. Два отличных набора слайдов на ICE здесь и здесь.
WebRTC является вариантом стандарта ICE, а также справочной библиотекой для сеансов P2P с STUN и TURN.
UPNP + Протокол интернет-шлюза - Некоторые маршрутизаторы поддерживают это для хостов, чтобы автоматически получать сопоставления портов.
libnice - это библиотека C с открытым исходным кодом для Linux (и может работать на Windows), которая реализует ICE.
libjingle - еще одна реализация ICE (на С++) от Google. Для Windows и Linux.
PJNATH - это библиотека в PJSIP наборе библиотек кодирования. Это хорошая реализация стека ICE (код C) и была перенесена на множество платформ. (Windows, Linux, Mac, iOS, Symbian и вскоре Android).
И, наконец, у меня есть вопиющая версия, чтобы вы могли использовать мою базу кода сервера STUN.
В некоторых случаях есть решения, см. UPnP: https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal
Мой домашний маршрутизатор позволяет это, в основном, NAT можно настроить автоматически с помощью соответствующего запроса с компьютера.
Я бы не стал рассчитывать на это, чтобы обеспечить значительное улучшение вашей доступности, поскольку не так много маршрутизаторов поддерживают и поддерживают его.
EDIT: @David предложил этот вопрос SO для библиотеки .NET для UPnP: Есть ли библиотека UPnP для .NET(С# или VB.NET)?
Я бы использовал технологию WebRTC в качестве среды с открытым исходным кодом для такого приложения.
Фактически это проект с открытым исходным кодом, который поддерживает все необходимые для одноранговых технологий:
Это может быть немного сложнее, чем то, что вы ищете, но TCP Hole Punching - это метод, который должен работать. http://en.wikipedia.org/wiki/TCP_hole_punching
В качестве альтернативы UPnP отлично работает для маршрутизаторов/брандмауэров, которые его поддерживают.
У вас есть еще один параметр, который Протокол сопоставления NAT-портов (NAT-PMP) NAT-PMP широко используется приложениями VoIP, такими как клиенты Skype или BitTorrent P2P.