我一直在网上寻找解决方案，但没有运气。
我们正在制作一个可以发送和接收数据的套接字。客户端和服务器版本都充当客户端和服务器。问题是，客户端服务器版本ip在使用NAT的网络上，这意味着，当服务器尝试接收消息时，它不会，因为服务器具有公共IP，我们似乎无法找到解决方案，如何收集数据。
SetIPProtectionLevel是Unrestricted，因此它应该可以工作。
感谢您的帮助。
我们尝试将服务器版本的IP更改为本地，然后从客户端发送到公共服务器ip，但没有运气。
从本地客户端ip到本地服务器ip它正在工作。
答案 0 :(得分：0)
如果一方不在NAT后面并且NAT后面的一方发送第一个数据包，那么这没有理由给你带来任何问题。请遵循以下规则：
1）在服务器上，检查主机拥有的所有IP地址列表。将UDP套接字绑定到每个 IP地址。如果服务器只有一个公共IP地址，并且这是唯一可以访问的地址，则可以跳过此步骤。
2）在收到请求的同一个套接字上发送UDP回复。这对于确保回复的源地址与目标地址匹配至关重要。
3）将UDP回复发送到与收到查询时完全相同的IP地址和端口。忽略另一端所说的关于它认为IP地址是什么或它认为它发送的端口的任何内容。
还有几点说明：
通过“服务器”，我的意思是不在NAT后面。如果客户端和服务器之间没有区别，那么请遵循双方的服务器规则，你会没事的。
这些规则适用于严格来说，数据包是否是回复。它们适用于您希望到达另一方的任何数据包。
请记住，您不能依赖数据包中的IP /端口信息来告诉您数据包来自哪个，因为NAT可以更改它。因此，您必须在数据报的有效负载中放入足够的信息才能执行此操作。理想情况下，期望端点的IP /端口可以随时更改，并将所有数据包发送到您上次从该特定客户端收到数据包的IP /端口。
答案 1 :(得分：0)
也许检查您的AntiVirus软件已安装。
我们必须发现一些AV sw打破了基于UDP消息传递的进程间通信 - 即使AV包含的防火墙部分已停用且我们自己的sw被置于可信的sw列表中。 有些AV产品似乎在IP堆栈中如此深入，并做了一些奇怪的事情来过滤掉可疑通信，可能会产生奇怪的影响。唯一有帮助的是卸载AV保护sw。
大多数影音公司对此类问题的支持非常差 - 所以我们最终不得不换成另一个AV sw品牌。