Прямые соединения TCP / IP в приложениях P2P - PullRequest
Новая
       52

Прямые соединения TCP / IP в приложениях P2P

4 голосов
/ 04 сентября 2008

Из сообщения Джоэла на Copilot :

Прямое подключение! Мы всегда делали все, что мы можем сделать, чтобы убедиться, что Fog Creek Copilot можно подключить в любом сетевая ситуация, несмотря ни на что межсетевые экраны или NAT на месте. к чтобы это произошло, обе стороны делают исходящие соединения с нашим сервером, который передает трафик от их имени. Ну, во многих случаях это не необходимо. Так что версия 2.0 делает что-то довольно умное: это настраивает начальное соединение через наш серверы, так что вы подключаетесь правильно прочь со 100% надежностью. Но потом как только вы все связаны, тихо, на заднем плане, ищет способ сделать прямую связь. Если не может, ничего страшного: вы просто продолжаете ретранслировать через наш сервер. Если вы можете сделать прямое одноранговое соединение, это молча переносит ваши данные на прямая связь. Вы не заметите все, кроме, возможно, гораздо быстрее связи.

Как они меняют соединение с сервером на соединение P2P?

Ответы [ 3 ]

9 голосов
/ 04 сентября 2008

Это довольно сложно и интересно. Я уверен, что некоторые детали неверны, но обзор таков:

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

Они решили попробовать эту технику дырокола. Компьютер A устанавливает соединение TCP с компьютером B, используя внешний IP-адрес B. Он не пройдет, но он сообщит маршрутизатору A, что ему нужно разрешить входящие пакеты от B на данный порт.

Компьютер B делает то же самое, но его сообщение доходит до A, поскольку маршрутизатор A открыл комбинацию порта / ip, которая соответствует отправленной B (здесь происходит какое-то волшебство порта - это не тривиально, но выполнимо).

Маршрутизатор B помнит, что B инициировал соединение с A на заданном порту и IP-адресе, и поэтому пакеты A теперь также правильно проходят через B через свой маршрутизатор.

Так что на самом деле все довольно просто, но в реализации есть детали, особенно касающиеся того, как порты назначаются новым TCP-соединениям, и как маршрутизаторы NAT обычно обрабатывают запросы TCP и как они отображаются на внешние порты. Эти детали интересны и сложны.

-Adam

1 голос
/ 04 сентября 2008

Я считаю, что простая версия состоит в том, что они сбрасывают соединение с сервером и заменяют его на соединение P2P.

Что-то вроде:

  1. Machine1 подключается к серверам второго пилота.
  2. Machine1 подключается к серверам второго пилота.
  3. Machine1 подключается к серверам второго пилота.
  4. Machine2 впоследствии подключается, и они начинают совместное использование экрана.
  5. Machine2 открывает порт, предназначенный для подключения к Machine1.
  6. Machine1 пытается подключиться к теперь открытому порту на Machine2.

Если это соединение установлено:

  1. Соединение с серверами второго пилота разорвано.
  2. Вместо этого данные передаются по прямому (P2P) соединению между двумя машинами.
1 голос
/ 04 сентября 2008

Существует методика, называемая Hole Punching , которая хорошо работает с NAT "Cone" (Cone - это техническая семья маршрутизатора). Это не на 100% уверенный метод, сегодня он хорошо работает с UDP на 80% маршрутизатора.

Существует несколько реализаций библиотеки для реализации дырокола: STUN ( wikipedia )

...