Соединение между двумя компьютерами через сокет?

Question

[snegirev_news]

Попытки реализовать p2p-сеть.
Есть 2 компьютера, выходящие в сеть через роутер, например. И есть сервер с белым ip.
Компьютеры открывают одно соединение на прослушку (5005 и 5006 порт, например), а вторым соединением соединяются с сервером.
Сервер получает Hello сообщения от компьютеров и запоминает адрес и порт отправителя, допустим это (ip-addr port:39392 иip-addr port:21213). Потом рассылает всем известным ему пирам эту информацию.
И вот когда с первого компьютера, я пытаюсь подключиться ко второму компу используя полученные ip и порт, то никакой реакции.
Каковы пути решения?

Answer 1

[res2001]

Видимо NAT мешает. В подобном случае NAT всем мешает.
Нужно либо настраивать NAT на шлюзе (проброс портов), либо обмениваться трафиком через сервер, а не напрямую.
Если приложение "для внутреннего использования" или для узкого круга лиц, то обычно нет проблемы настроить NAT, если же предполагается массовое распространение, то это не вариант и нужно искать обходные пути.
Для UDP протокола есть вариант использовать внешний STUN сервер. Для TCP, по моему, этот вариант не работает.

Comments

[snegirev_news]

В том и проблема, что пишется для массового распространения.
Если попробовать использовать STUN сервер и UDP, то какое его отличие от сейчас используемого у меня сервера с белым ip?
Можешь объяснить, если не сложно, механизм действий в данном случае?!

[res2001]

snegirev_news, TCP создает сессию, адрес сессии определяется 4 параметрами:
адрес отправителя и получателя, порт отправителя и получателя.
UDP сессий не создает и идентифицируется только по адресу и потру отправителя.
NAT по умлчанию работает так, что наружу пропускает все, а внутрь только ответы на внутренние запросы с теми же параметрами пакетов.
Т.е. для TCP NAT запомнит все 4 параметра, а для UDP только 2.
Соответственно ваша программа сначала идет на STUN сервер по UDP, NAT ее пропускает и запоминает параметры пропущенного пакета (чтоб пропустить ответ). STUN сервер сообщает ваш адрес и порт абоненту и абонент может, используя эту информацию отправить вам на прямую данные.
Для TCP схема не работает, т.к. NAT сохранит адрес и порт получателя исходящего пакета и пропустит пакеты только с этого адреса и порта, т.е. только от сервера, а от других абонентов - нет.
STUN сервера есть свободные. Это не только сервер, но и протокол, есть RFC и проч.
Схема от вашей практически не отличается, видимо отличие только в протоколе - UDP. Из-за этого в случае со STUN сервером она работает, а в вашем - нет.

[snegirev_news]

Большое спасибо, видимо и правда в этом была проблема, что я использовал TCP. Попробую использовать UDP и посмотрим на результат

[res2001]

snegirev_news, Удачи!
PS: У UDP свои тараканы - нет гарантии доставки пакетов.

Answer 2

[Владимир]

все же я думаю что неплохо было бы еще раз почитать про p2p
википедия отлично помогает

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

Answer 3

[Ярослав]

Давайте ещё раз.
На каком порту вы начинаете слушать входящие соединения?

Работать всё, на примере TCP, должно так:
1. Клиент устанавливает соединение с публичным сервером:
192.168.1.100:12345 -> 1.2.3.4:80
Порт 12345 со стороны клиента выделяется, как правило, автоматически операционной системой клиента.

2. NAT выделяет публичную пару Ip-адрес: порт для этого соединения, и запоминает её:
(клиент) 192.168.1.100:12345 -> (NAT)(5.6.7.8:11111) -> (сервер)1.2.3.4:80
Соответственно, с точки зрения сервера, в нему подключились с пары адрес:порт 5.6.7.8:11111

3. Теперь, внимание!
Клиент, ожидая входящие соединения, начинает слушать на порту 12345, поскольку именно для этого порта пробита "дырка" в NAT.
Эта технология так и называется: Hole Punching.
Про другие порты, открытые на этом клиенте, NAT ничего не знает.

4. Кто-то снаружи устанавливает TCP-соединение с парой адрес:порт 5.6.7.8:11111.
NAT знает, что за публичной парой 5.6.7.8:11111 скрывается, на самом деле, "серая" пара 192.168.1.100:12345, подменяет в TCP SYN-пакете destination address и destination port c 5.6.7.8:11111 на 192.168.1.100:12345, и отправляет этот ip-пакет клиенту.
Клиент, получив запрос на соединение на порту 12345, подтверждает установление соединения.

Соответственно, есть три момента, которые стоит проверить:
1. После установления соединения с внешним сервером, клиент должен поднять Listening Socket на том же source TCP port, с которым было установлено соединение с внешним сервером
2. На NAT должна быть включена функциональность Hole Punching
3. Для успешного установления соединения между находящимися за NAT узлами по их публичным адресам, на NAT должна быть включена отвечающая именно за это функциональность Hairpinning.