Пробивка отверстий TCP

Я пытаюсь реализовать пробивание отверстий TCP с помощью сокета Windows, используя mingw toolchain. Я думаю, что процесс правильный, но дыра , похоже, не подходит. Я использовал этот как ссылку.

1. A и B подключаются к серверу S
2. S отправляет на A , B маршрутизатор IP + порт, который он использовал для подключения к S
3. S делает то же самое для B
4. A запускает 2 потока:
   • Один поток пытается подключиться к маршрутизатору B с информацией, отправленной S
   • Другой поток ожидает входящего соединения на том же порте, который использовался для подключения к его маршрутизатору, когда он подключен к S
5. B делает то же самое

У меня нет проблем с кодом, я думаю, так как:

• A и B действительно понимают друг друга IP и порт для использования
• Они оба прослушивают порт, который они использовали для подключения к своему маршрутизатору, когда они связались с сервером
• Они оба подключаются к правильному IP-адресу и порту, но время ожидания истекает (ошибка кода 10060 )

Мне что-то не хватает?

РЕДАКТИРОВАТЬ: С помощью проводника процессов я вижу, что одному из клиентов удалось установить соединение с одноранговым узлом. Но партнер, похоже, не считает, что соединение установлено.

Вот что я сделал с помощью Wireshark.Для примера, сервер S и клиент A находятся на одном компьютере. Сервер S прослушивает определенный порт ( 8060 ), перенаправленный на этот компьютер. B по-прежнему пытается подключиться по правильному IP-адресу, потому что видит, что публичный адрес A , отправленный S , равен localhost , и поэтому использует вместо этого публичный IP-адрес S . (Я заменил общедоступные IP-адреса заполнителями)

РЕДАКТИРОВАТЬ 2 : Я думаю, что путаница связана с тем, что данные входящих и исходящих запросов на соединение передаются на один и тот же порт. Что, кажется, нарушает состояние соединения, потому что мы не знаем, какой сокет получит данные из порта. Если я процитирую msdn:

Параметр сокета SO_REUSEADDR позволяет сокету принудительно связываться с порт используется другим сокетом. Второй сокет вызывает setsockopt с параметр optname установлен на SO_REUSEADDR , а параметр optval установлен до логического значения TRUE перед вызовом привязки на том же порту, что и оригинальная розетка. После успешного связывания второго сокета поведение всех сокетов, привязанных к этому порту, не определено.

Но соединение через тот же порт требуется методом пробивки отверстий TCP, чтобы открыть дыры !