Одноранговая связь в сложных мультиподсетях LAN
Мы разрабатываем приложение P2P и stucked в части создания коммуникации между 2 коллегами, которые находятся в той же локальной LAN, но 2 различных подсетях.
Мы знаем, что существует много случаев, что 2 определенных ПК в той же LAN являются определенно "несоединяемой" причиной настроек некоторых маршрутизаторов. То, что мы пробуем, должно только понять ситуацию и узнать лучшее, которое мы можем сделать. (с нашими ограниченными знаниями о сетях и Вашей справке)
Рассмотрите LAN со структурой как следующее число. Предположим, что LAN разработана нашим клиентом, и мы ничего не знаем. Мы просто наблюдаем LAN с точки зрения ПК, который установил нашу программу. Таким образом все, что мы знаем, является нашим localIP/subnetMask и общим общедоступным IP всей LAN. (Остальное неизвестно и отображено как облако),
У нас есть несколько вопросов, что мы высоко appricated для любого ответа:
Предположим, что то, когда PC1 многоадресно передают пакет и пакет, достигает PC2 так или иначе. Какой IP-адрес будет PC2 видеть отправителя пакета: LocalIP PC1 (как в рисунке 192.168.1.111) или внешний IP Router_A_1 или Router_A?
После № 1, если PC2 отвечают с другим пакетом (одноадресная передача) к IP, который PC2 видят в № 1, пакет достигнет PC1?
В глобальных случаях № 2, каков может быть соответствующий IPAddress что PC1 и использование PC2 для отправки пакетов в другой? (Или это совпадает с, мы делаем по Интернету с 2 ПК позади маршрутизаторов NAT: upnp, перфорация дыры или промежуточный Суперузел?)
Есть ли какой-либо случай, что PC1 и PC2 присвоены с тем же IP-адресом? Если это верно затем:
- a. Это - "легальный" случай?
- b. Что относительно IP отправителя, который PC2 видит в № 1 и ответе для № 2?
Обновите дополнительный вопрос:
- Действительно ли это верно, что, если 1 одноранговый узел многоадресно передал и пакет может достигнуть другого однорангового узла затем, эти 2 ПК "способны одноадресной передачей" - и если многоадресный пакет не может достигнуть другого однорангового узла затем, 2 ПК разрушены? Это верно для "способного одноадресной передачей-> способный многоадресной передачей"?
Я написал несколько одноранговых приложений и могу сказать вам, что доступность одноранговых узлов является основной проблемой для таких приложений. Вот несколько указателей:
если вы используете TCP, ваша единственная надежда - UPnP. Однако нельзя предполагать, что он всегда доступен. Фактически UPnP (а) в основном поддерживается домашними сетевыми маршрутизаторами (б) он часто отключается, поскольку люди не видят в нем особой ценности или не видят в нем никакой ценности, поэтому его поддержка носит спорадический характер. Ваши шансы еще меньше, если ваши клиенты находятся за 2-мя уровнями маршрутизаторов, каждый из которых выполняет свой собственный NAT. Но если вы можете сказать своим клиентам включить UPnP или указать UPnP в качестве предварительного условия для вашего приложения, тогда это правильный вариант.
Другой вариант - использовать UDP и пробить отверстие в маршрутизаторе, но вам понадобится внешний агент, который отслеживает адрес однорангового узла и сопоставляет идентичность хоста с глобально доступным IP-адресом (в вашем случае он, вероятно, будет развернут в «Неизвестном»). Обратите внимание, что TTL отверстий для контактов UDP обычно очень короткое (по моим оценкам, от 20 секунд до 5 минут), поэтому вам придется часто пинговать своего агента. Другая проблема с UDP заключается в том, что вам может потребоваться реализовать собственный протокол управления потоком, если ваше приложение обменивается битами данных, размер которых превышает 1 пакет.
Надеюсь, это поможет.
Топология вашей сети в лучшем случае ненадежна и трудна в обслуживании.
Учтите это (при условии / 24 подсети): ПК1 (192.168.1.111) пытается отправить пакет на ПК2 (192.168.1.22). Почему Router_A_1 (или даже Router_A) должен пересылать этот пакет через «неизвестное» облако в другую подсеть? Что касается маршрутизаторов "A", пакет уже находится в подсети, которой он принадлежит. Возможно взломать некоторые таблицы маршрутизации в маршрутизаторах для пересылки определенных адресов - но вы обнаружите, что именно отсюда возникает «ненадежная и сложная» часть (и может быть даже непрактичной в зависимости от того, что находится в «неизвестном» облаке).
Есть ли причина, по которой вы не могли просто выделить другой / 24 для подсетей маршрутизатора "B"? Например, 192.168.2.0/24?
Вы не сказали, но ..
Если вы используете традиционную 24-битную маску подсети (т.е. обе сети - 192.168.1.0/24), то эти машины никогда не смогут обмениваться данными потому что по определению они будут пытаться разрешить MAC-адрес широковещательной рассылкой, а не идти к шлюзу для маршрутизации, поскольку предполагается, что машина находится в локальной сети.
Это можно исправить, назначив ПК1 адрес в другой сети.
SO PC1 = 192.168.2.111
В этом случае, пока промежуточные маршрутизаторы имеют правильные записи в таблице маршрутизации и разрешают многоадресную рассылку и разрешают любой порт / протокол, который вы пытаетесь использовать, он должен работать.