2017-02-22 13 views
0

Я пытаюсь создать одноранговую игру, где каждый игрок является одновременно сервером и клиентом с сокетами tcp. Сокеты могут подключаться отлично, когда я использую локальный ip: s, но, конечно, не удается, когда я пытаюсь использовать внешние ip: s.Если он знает мой внешний адрес и порт, может ли другой компьютер из Интернета запустить tcp-сокет в сторону моего компьютера? (Без переадресации портов)

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

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

Но я не нашел никакой информации нигде, если это так, как работает переадресация портов. Если компьютер A отправляет запрос с локального адреса и порт на сервер, а маршрутизатор назначает этот адрес + порт внешнему адресу + порту, а сервер указывает компьютеру B, адрес + порт которого должен использоваться. Может ли компьютер B использовать этот внешний адрес + порт для подключения к компьютеру A и запустить с ним tcp-сокет? Есть ли способ узнать, что этот внешний адрес + порт остается прежним, когда другой компьютер делает запрос против них?

+0

как вы справляетесь с брандмауэром и ISP-блоком какого-либо порта? создать какой-то сервер vpn или туннелирование, чтобы это имело смысл для меня –

ответ

0

Нет, TCP не работает.

Исходный порт, который был использован, чтобы поговорить с сервером рандеву будет преходящими и особенностями конкретного исходного соединения TCP сокета и может быть использован только в качестве места назначения для возврата трафика на же связи с сервера рандеву , и не может использоваться третьей стороной для создания новых входящих соединений.

Типичное (только?) Практическое решение, когда задействованы NAT, и переадресация порта недоступна, чтобы иметь это центральное серверное реле все сообщения двунаправленно между одноранговыми узлами.

+0

Он утверждает, что «каждый игрок является одновременно сервером и клиентом». – EJP

+0

@EJP, который не делает недействительным то, что я сказал. Одноразовая пара адресов/портов, которую центральный сервер рандеву обнаруживал бы из входящего соединения, сделанного одним одноранговым узлом, не имеет никакого отношения к другому партнеру при попытке подключиться обратно. – Alnitak

+0

@ EJP Я должен квалифицировать это - это бесполезно, если это не дрянной NAT/брандмауэр, который действительно создает стабильные сопоставления исходящих портов, а затем позволяет третьим лицам подключаться к ним. – Alnitak

0

Проблема в том, что большинство людей не выставляют свои ПК непосредственно в Интернет. У них есть маршрутизатор с внешним адресом. Когда вы отправляете пакет на свой IP-адрес, он переходит к своему маршрутизатору. Маршрутизатор не знает, куда его пересылать и какой порт использовать без переадресации портов.

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

0

Отверстие для отверстий - это то, что я искал. https://en.wikipedia.org/wiki/Hole_punching_(networking)

+0

Такая пробивка отверстий работает только в том случае, если это разрешает устройство NAT. Не все, потому что это действительно дыра в безопасности.Если NAT-устройство также работает в качестве брандмауэра, оно НЕ ДОЛЖНО разрешать другим третьим сторонам делать входящие подключения к временному порту, который был открыт исходящим соединением. – Alnitak

+0

На самом деле приличный брандмауэр NAT не должен позволять удаленному IP-адресу _same_ (в вашем случае серверу rendezvous) устанавливать новое соединение с этой парой адресов/портов, не говоря уже о какой-либо третьей стороне. – Alnitak

Смежные вопросы