P2P рукопожатие без центрального сервера

1

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

Теперь мне нужно адаптировать это приложение для работы через Интернет. Без особого внимания к сетевому программированию я не уверен, как достичь этого без какого-либо центрального сервера (для объявления присутствия и т.д.). Это не вариант.

Предположим, у меня есть приложение, работающее в режиме сервера на моем компьютере, которое находится за домашней сетью. У вас (читателя) есть приложение в режиме клиента, и нам нужно подключиться. Ни у кого из нас нет статических IP-адресов. Есть ли способ для клиента достичь сервера? И сервер, и клиент могут определить свои общедоступные IP-адреса, но помимо этого, я не уверен, что делать.

Любые рекомендации будут оценены.

РЕДАКТИРОВАТЬ: На основе ответов, некоторые пояснения в порядке. Мой вопрос не об открытии. Клиент и сервер могут запрашивать свои общедоступные адреса, и пользователи могут обмениваться этими IP-адресами на какой-либо другой носитель. Вопрос заключается в том, как установить соединение, когда известны друг друга, но обе стороны находятся за сетями, которые не имеют соответствующих переадресаций портов. Мое приложение использует порт 51200 по умолчанию по TCP, например.

Теги:
networking
network-programming
p2p

4 ответа

2
Лучший ответ

Несколько месяцев назад я искал подобное решение, но, к сожалению, я застрял, и отныне я его бросил.

Люди говорят, что вы можете использовать перфорирование отверстий UDP или перфорирование отверстий в TCP, но я не мог этого сделать (я не специалист в компьютерных сетях, хотя). Будет ли это работать или нет, зависит от самой сети.

Вот вопрос, который я изначально задал, может быть, это будет полезно для вас. Честно говоря, я не хочу убивать ваши надежды, но я боюсь, что это может быть тупиком. :(

Поделиться
3

Я изучаю эти темы на пару недель до месяца. Я узнал, что методы перфорации отверстий UDP, которые предназначены для истинной прямой связи между двумя сверстниками, несовершенны из-за некоторых возможных комбинаций типов NAT. Это означает, что перфорация отверстий UDP не всегда будет работать отлично. Кроме того, существуют стандартные протоколы для обработки этого процесса, которые мы можем использовать, вместо того чтобы писать собственные. Вам не нужно начинать с нуля, что я и сделал, написав собственный сервер ретрансляции. Вместо этого мы можем защелкнуть существующие стандарты (доведя это позже).

Способ применения 100% -ной работоспособности, хотя и не всегда полностью прямой, заключается в том, что в случаях, когда соединение p2p невозможно, используйте сервер ретрансляции. Процесс обнаружения того, возможно ли истинное соединение p2p, был стандартизован ICE, TURN и STUN. iirc, TURN имеет в нем STUN-сервер. Я недостаточно узнал о применении этих 3, и я не буду входить в разные типы NAT. Все, что я знаю, заключается в том, что использование ICE/TURN/STUN, по-видимому, является стандартизированной стратегией в пресечении проблемы NAT. Это может облегчить истинное p2p и предложить услуги ретрансляции, когда это необходимо. Это все, что я могу сказать, пока я не узнаю больше.

Примечание. Я использую термин p2p в этом ответе, чтобы отличить истинно прямое соединение между двумя конечными точками, чтобы не путать с сетями оверлея и т.п.

Продвинутые пользователи: возможно получить более прямые возможности p2p-соединений, введя более сложные стратегии для сотрудничества с симметричным поведением NAT, такие как прогнозирование портов и т.д. Но я обнаружил, что введенные сложности являются дорогостоящими как для вашего программирования, так и для NAT и, возможно, не стоит того. Извините, но у меня нет ссылок на меня, демонстрирующих эти методы. Я буду обновлять ссылки позже.

Я не объяснил подробно различные типы возможностей подключения NAT. Там есть RFC, и я буду пытаться обновить свой ответ ссылками в будущем. Посмотрим. Но дело в том, что вы можете предотвратить много этого обучения, переориентировавшись на реализацию TURN/STUN/ICE, узнаете, как они реализованы и как вы можете использовать стандартизованное поведение

Решения

  • PJSIP - содержит автономную библиотеку NAT-обхода высокого уровня для C/C++, также имеет привязки для других langauges. Если вам просто нужен субкомпонент библиотеки NAT Traversal, см. PJNATH
  • LibJingle - стек P2P (одноранговый) и RTC (в режиме реального времени), который основывается на XMPP. Обратите внимание, что многие из реализации LibJingle не совместимы с фактической спецификацией XMPP Jingle и дополнительными спецификациями.

Они могут значительно усложнить программу, поэтому она может быть вынуждена сама реализовать некоторые из механизмов.

документы

IETF

РЛК

Microsoft

Заметки

Я слышал, что возможная миграция на IPv6 может подавить проблему обхода NAT, но [возможно, нет]. Кто-то может просветить эту тему. В любом случае, переход к IPv6 кажется медленным с моей неопытной точки зрения, и я не буду считать его решением.

Поделиться
0

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

Кроме того, перфорация отверстий udp или tcp является совершенно другой вещью и использует, угадайте, что: центральный сервер.

Поделиться
  • 0
    Благодарю. Обе стороны могут запрашивать свои общедоступные IP-адреса, а также обмениваться IP-адресами друг друга. Так что проблема не в открытии. Это больше о том, как связаться друг с другом за их домашней сетью, которая не имела бы соответствующих переадресаций портов.
0

Если вы используете IPv6, это возможно, но вам все равно нужно знать адрес других сторон. Это также возможно, если вы используете службу DynDns, но это уже некая центральная инфраструктура.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню