P2P UDP 打洞失败，求指教
首先两个客户端通过服务端交换公网IP
然后已经成功接收对方公网IP的客户端马上分别对对应公网IP发送
但是无论怎样发送都接收不到
是不是还要做点什么的？

试了网上很多例子都不成功
[最优解释]
那就靠猜测，通过连续发送两次数据包根据返回的端口号猜测端口变化规律
[其他解释]
1,猜是一种
2，既然打通了，那就对指定的ip 指定的端口发送数据
3，接收方 监听对应的端口吧
4，这个还好像与路由或交换机的是否支持和设置有关系
5，一起研究吧 不太熟悉这方面
[其他解释]
不是说得到对方公网ip就可以发送成功的 排除路由的问题(牵扯到端口映射) 也是要A先向B发生打洞

报文 这时B的路由肯定会丢弃 但是这时A的路由会“认识”B(因为你往B发了数据) 这时候再通过

发送报文给服务器 让服务器“告诉”B 我的路由已经认识你了 你发消息我 让你的路由也“认识”我

然后B收到服务器的打洞命令 发送打洞报文给A A的路由已经“认识”B 所以链路已通 可以顺畅使用

udp开始通信
[其他解释]
两个客户端是不是在同一局域网？
[其他解释]
其实就是根据服务器的中转 先得到互相的ip信息 然后一方先发送报文让自己的路由不会丢弃对方的报文

然后通过服务器通知对方 也向你发送报文(因为这时候你怎么发送对方都是收不到的) 当对方知道你已经打洞了

再向你发送报文 这时候互相之间就已经“认识了” 后续就可以正常的发送需要的数据了
[其他解释]
你的两个客户端是用几个路由出去的?
[其他解释]

引用:

引用:
其实就是根据服务器的中转 先得到互相的ip信息 然后一方先发送报文让自己的路由不会丢弃对方的报文

然后通过服务器通知对方 也向你发送报文(因为这时候你怎么发送对方都是收不到的) 当对方知道你已经打洞了

再向你发送报文 这时候互相之间就已经“认识了” 后续就可以正常的发送需要的数据了

通知对方有没有打洞这步就没做，我就是……

就是因为你没做 所以A向B发的包永远被丢弃 你还不明白udp打洞的原理...
[其他解释]

引用:

引用:看了下逻辑没什么问题,当时我做实验的时候是通过两个路由两个ADSL出去,服务器收到的外网地址是不同的.你这种同外网地址相同的没有做过,可能路由会做某些处理.

两种情况都试过，不知道为什么不行，你以前做的成功了吗？能不能放源码出来看看，或者大概逻辑上是否和我的一样？

源码
[其他解释]
我先回一下帖子，没分了。
[其他解释]
后来看到书上说这个过程只适用于Cone NAT的情况，Symmetric NAT，A打洞的端口会重新分配，B无法知道这个端口

那么要怎样实现呢
[其他解释]

引用:

那就靠猜测，通过连续发送两次数据包根据返回的端口号猜测端口变化规律

后来测试发现，同一程序发去两个不同服务端的IP和端口都是一样的，说明应该是Cone模型的路由
可是为什么打不通还不清楚
[其他解释]

引用:

1,猜是一种
2，既然打通了，那就对指定的ip 指定的端口发送数据
3，接收方 监听对应的端口吧
4，这个还好像与路由或交换机的是否支持和设置有关系
5，一起研究吧 不太熟悉这方面

我发现我的路由应该是Cone NAT，理论上应该能打通，但是还是不行，不知道为什么
[其他解释]

引用:

两个客户端是不是在同一局域网？

无论在同局域网和非同局域网都测试过，不行
[其他解释]

引用:

其实就是根据服务器的中转 先得到互相的ip信息 然后一方先发送报文让自己的路由不会丢弃对方的报文

然后通过服务器通知对方 也向你发送报文(因为这时候你怎么发送对方都是收不到的) 当对方知道你已经打洞了

再向你发送报文 这时候互相之间就已经“认识了” 后续就可以正常的发送需要的数据了

通知对方有没有打洞这步就没做，我就是用服务端交换两个客户端的IP和端口后，就直接多次互发UDP，单recvfrom一直没反应
[其他解释]

引用:

你的两个客户端是用几个路由出去的?

无线路由接AD，TP-LINK的
[其他解释]
http://download.csdn.net/detail/rsdtt/4842876

源码已上传，这个东西搞了我一个多星期还没搞成功
[其他解释]
期待楼主，做好 放马
[其他解释]
看了下逻辑没什么问题,当时我做实验的时候是通过两个路由两个ADSL出去,服务器收到的外网地址是不同的.你这种同外网地址相同的没有做过,可能路由会做某些处理.
[其他解释]
而且怎么告诉A和B 对方的ip 是通过A和B像服务器发数据 服务器recvfrom里面的地址结构来的 A向B发完

打洞命令 A在向服务器发送命令 让服务器通知B往A发打洞命令 这时候将A的地址结构传给B B再用这个

地址结构向A发打洞命令 因为A前面已经给B发过命令了 所以这时候B的打洞命令就不会被A的路由丢弃了 也

因为现在B给A发命令了 所以后续A的数据也不会被B的路由丢弃...
[其他解释]

引用:

而且怎么告诉A和B 对方的ip 是通过A和B像服务器发数据 服务器recvfrom里面的地址结构来的 A向B发完

打洞命令 A在向服务器发送命令 让服务器通知B往A发打洞命令 这时候将A的地址结构传给B B再用这个

地址结构向A发打洞命令 因为A前面已经给B发过命令了 所以这时候B的打洞命令就不会被A的路由丢弃了 也

因为现在B给A发命令……

不是的，我的意思好是：AB已同时发送一次UDP给服务端（称为S吧），然后S根据这两个不同recvfrom的地址提取交换然后分别发送给AB，这时我就挂起AB的recvfrom之后不断向S返回的对方地址发送数据，其实就是已经互相通过S得知bind了的IP和端口
[其他解释]
LS正解。
如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。
[其他解释]

引用:

看了下逻辑没什么问题,当时我做实验的时候是通过两个路由两个ADSL出去,服务器收到的外网地址是不同的.你这种同外网地址相同的没有做过,可能路由会做某些处理.

两种情况都试过，不知道为什么不行，你以前做的成功了吗？能不能放源码出来看看，或者大概逻辑上是否和我的一样？
[其他解释]

引用:

LS正解。
如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。

其实我的方法就是将你说的这整个过程统一化处理了
[其他解释]
我也在研究这东西,不过我发现如果是P2P打洞模块做成DLL,拿去做文件传输就是不能,不知道为什么?希望研究P2P技术的交流一下.我的QQ:1049568282
[其他解释]
终于成功打洞了，之前那个失败的估计是因为路由对那个端口的时效性原因，这次修改了接收到服务端返回对方的IP马上向对方IP打洞，感谢bbs上的朋友讨论，服务端暂时还在运行， 使用方法第一方先点start clean，然后对方也点start，然后双方sendto server即可打通

源码正在审核，等下发上

接下来尝试TCP的打洞看看，到时候另外开贴讨论，感谢各位论坛朋友
[其他解释]

引用:

引用:引用:看了下逻辑没什么问题,当时我做实验的时候是通过两个路由两个ADSL出去,服务器收到的外网地址是不同的.你这种同外网地址相同的没有做过,可能路由会做某些处理.

两种情况都试过，不知道为什么不行，你以前做的成功了吗？能不能放源码出来看看，或者大概逻辑上是否和我的一样？

源码
……

感谢你的源码得到启发，估计我的路由的时效性问题，我把代码写成收到服务端发来的对方IP信息即时开始打洞就成功了
[其他解释]
服务端运行几天供大家测试
http://download.csdn.net/detail/rsdtt/4850266