Socket UDP с локального компьютера, код ошибки 10049

Question

Я искал в Интернете решение, но не повезло.

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

SetIPProtectionLevel не ограничен, поэтому он должен работать.

Спасибо за помощь.

Мы попытались изменить ip на серверную версию на локальную, а затем отправить с клиента на общедоступный сервер ip, но не повезло.

С локального клиента ip на локальный сервер ip работает.

Answer 1

Нет причин для того, чтобы это создавало проблемы, при условии, что одна сторона не находится за NAT, а сторона, которая находится за NAT, отправляет первый пакет. Просто следуйте этим правилам:

1) На сервере проверьте список всех IP-адресов, которые имеет хост. Свяжите гнездо UDP с каждый IP-адрес. Вы можете пропустить это, если на сервере только один общедоступный IP-адрес, и это единственный адрес, на который он будет установлен.

2) Отправьте ответ UDP на тот же сокет, на который вы получили запрос. Это важно для обеспечения того, чтобы адрес источника ответа соответствовал целевому адресу.

3) Отправьте UDP-ответ точно на тот же IP-адрес и порт, на который вы получили запрос. Игнорируйте все, что говорит другой конец, о том, что он думает о своем IP-адресе, или о том, какой порт он считает отправкой.

И несколько замечаний:

Под «сервером», я имею в виду ту сторону, которая еще не за NAT. Если у вас нет различия между клиентом и сервером, следуйте правилам сервера для обеих сторон, и все будет в порядке.

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

Помните, что вы не можете полагаться на информацию IP/port в пакете, чтобы сообщить вам, откуда пришел пакет, поскольку NAT может его изменить. Поэтому вам нужно будет разместить достаточную информацию в полезной нагрузке дейтаграммы для этого. В идеале ожидайте, что IP-порт конечной точки может измениться в любое время и отправить все пакеты на IP/порт, с которого вы последний раз получали пакет от этого конкретного клиента.

Answer 2

Возможно, проверьте установленное программное обеспечение AntiVirus.

Нам пришлось выяснить, что некоторые AV-файлы нарушили нашу межпроцессную связь, основанную на обмене сообщениями UDP - даже когда часть брандмауэра включена AV, и наш собственный sw был помещен в список доверенных sw. Некоторые аудиовизуальные продукты, похоже, так глубоко вложены в стек IP и делают странные вещи, чтобы отфильтровать подозрительные сообщения, что могут быть странные эффекты. Единственное, что помогло - это удаление AV-защиты sw.

Поддержка большинства AV-компаний для таких проблем была очень плохой - так что нам, наконец, пришлось перейти на другой бренд AV sw.