@daniil14056

Как связать клиенты с клиентом в разных сетях?

Как написать простой Чат-Клиент, который сможет отправлять сообщение другому Клиенту в другой сети, на другом полушарии. Чат не нужен конечно, но я не пойму как связать два компьютера и возможно ли. Все примеры в инете работают только в Локальной сети, либо через Сервер. Но Блокчейн же работает, как-то без Сервера, просто связывая Клиентов. А как это сделать я не пойму. Вот предположим, есть отправитель чей внешний IP 32.12.124.9, но внутри сети есть много машин с таким же внешним IP. И есть получатель, который расположен в сети WiFI с внешним iP 89.211.1.1, и внутренним 192.168.1.32, и таких машин в той сети там 10. И как мне достучаться именно до этого клиента?

Нужно написать Клиент, который сможет подключиться к другому клиенту в разный сетях. языки JAVA, node JS.
P.s С теорий у меня все плохо.
  • Вопрос задан
  • 138 просмотров
Решения вопроса 2
Но Блокчейн же работает, как-то без Сервера
Кто вам такое сказал? Это не соответствует действительности, сеть биткойн работает без центрального сервера, а не без сервера вообще.
А блокчейн это база данных, она никого не связывает, она храниться.

Вот предположим, есть отправитель чей внешний IP 32.12.124.9, но внутри сети есть много машин с таким же внешним IP.
В сети только одна машина с таким IP. Не может их быть две или больше.

И есть получатель, который расположен в сети WiFI с внешним iP 89.211.1.1, и внутренним 192.168.1.32, и таких машин в той сети там 10. И как мне достучаться именно до этого клиента?
Никак. Это невозможно. Клиент может достучаться к кому-то, а к нему достучаться невозможно.
Ответ написан
@yaror
10 лет в мобильном телекоме
Здесь, всё-таки, придётся лезть теорию.

В общем виде, технология называется TCP Hole Punching: https://en.wikipedia.org/wiki/TCP_hole_punching

Работает она так:
Есть маршрутизатор с внешним ip-адресом 1.2.3.4 и спрятанной за ним сетью 192.168.0.0/24.
Допустим, находящееся за NAT устройство с Ip-адресом 192.168.0.100 решило вылезти в Интернет и подключиться к серверу с ip-адресом 5.6.7.8 к порту 8080.
Устройство поднимает TCP-соединение: со стороны устройства пара ip-адрес:порт будет, допустим, 192.168.0.100: 1111, а со стороны принимающей стороны 5.6.7.8:8080.
Маршрутизатор, пропуская сквозь себя эти пакеты, подменяем ip-адрес и, что важно, порт спрятанного за ним устройства: на, предположим, 1.2.3.4:7890.

Если на маршрутизаторе включен TCP Hole Punching, то он начинает преобразовывать пары адрес-порт 192.168.0.100: 1111 -> 1.2.3.4:7890 не только для соединений, исходящих изнутри, но и для входящих соединений снаружи.
Это значит, что, начиная с момента установки соединения "изнутри наружу", запрос на TCP-соединение из интернета к 1.2.3.4:7890 будет прокинут маршрутизатором до спрятанного устройства, и дойдёт до 192.168.0.100: 1111.

Получается, клиентская сторона для приёма соединений из-за NAT должна подготовиться следующим образом:
1. Установить соединение с каким-то узлом в Интернет. Вообще неважно с кем: нам надо просто "пробить дырку" в NAT для приёма входящих соединений. Установив соединение, мы запоминаем source port.
2. Создаём Listening socket на порту, запомненном в предыдущем шаге. Теперь мы можем принимать входящие соединения из интернет!

И всё бы здорово, но возникает следующий вопрос: номер порта, на котором мы слушаем, маршрутизатор подменит совершенно непредсказуемым образом.
Если мы хотим установить прямое соединение с устройством, которое тоже находится за NAT, как нам узнать, к какой публичной паре Ip-адрес:порт нам цепляться? Ведь каждый раз номер порта может непредсказуемо меняться!

Ответ здесь один: нужен посредник - что-то типа каталога. Сервер с публичным ip-адресом, на котором можно зарегистрироваться. Ну никак без него!

Работать это может так:
1. Есть каталог с ip-адресом, допустим, 11.12.13.14, принимающий входящие соединения на порту 80.

2. Устройство А с ip-адресом 192.168.0.100, находящееся за NAT 1.2.3.4, готовится к приёму входящих соединений. Оно устанавливает TCP-соединение с каталогом:
192.168.0.100:1111 ===> 11.12.13.14:80.
NAT A в проходящих сквозь него ip-пакетах преобразует ip-адрес и номер порта для спрятанного за ним устройства, и запоминает это соответствие:
192.168.0.100:1111 <-> 1.2.3.4:1112.
С точки зрения каталога, он принял такое входящее TCP-соединение:
1.2.3.4:1112 ===> 11.12.13.14:80, ибо реальную адресацию устройства A ему узнать просто неоткуда. Ну и ладно: всё и так прекрасно работает!

3. Устройство B с ip-адресом 192.168.2.200, находящееся за NAT 5.6.7.8, устанавливает TCP-соединение с каталогом:
192.168.2.200:2221 ===> 11.12.13.14:80.
NAT B в проходящих сквозь него ip-пакетах преобразует ip-адрес и номер порта для спрятанного за ним устройства, и запоминает это соответствие:
192.168.2.200:2221 <-> 5.6.7.8:2222.

4. Устройство B спрашивает у каталога: "А кто к тебе ещё подключен?"
Каталог ответчает: "Да вот есть один такой, 1.2.3.4:1112"

5. Устройство B устанавливает TCP-соединение с полученным от каталога ресурсом:
192.168.2.200:9876 ===> 1.2.3.4:1112

NAT B подменяет и запоминает ip-адрес и номер порта устройства B: 192.168.2.200:9876 -> 5.6.7.8:4321

Соответственно, на NAT A прилетает запрос на установление соединения:
5.6.7.8:4321 ===> 1.2.3.4:1112

NAT A смотрит в таблицу NAT-трансляций, видит там знакомый номер порта, и подставляет из таблицы ip-адрес и номер порта устройства A: 1.2.3.4:1112 -> 192.168.0.100:1111

6. Устройство A получает запрос на подключение:
5.6.7.8:4321 ===> 192.168.0.100:1111

Собственно, в зависимости от требований, сервер каталога можно:
1. Написать самому
2. А можно не изобретать велосипед, и воспользоваться готовыми реализациями того же протокола STUN
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@res2001
Developer, ex-admin
Маршрутизация + NAT. Изучайте теорию IP сетей, если хотите разобраться.
Блокчейн живет в таком же интернете как и все остальные, поэтому работает по стандартным механизмам.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы