7880
社区成员
6.4w+
社区内容
- 主页
p2p的UDP打动技术的问题？？
p2p的UDP打动技术的介绍 都是客户端（ClientA,ClientB）使用UDP与服务器通信
，服务器获得ClientA的NAT分配的IPA 和 PORTA,ClientB的NAT分配的IPB PORTB,
把双方地址与端口告诉对方，安后ClientA借助服务器通知ClientB 往 ClientA方
向发送UDP包，ClientA 往 ClientB方向发送UDP包，建立连接。
问 客户端在开始连接服务器时是否能使用TCP连接来获得双方的ip和port
，服务器获得ClientA的NAT分配的IPA 和 PORTA,ClientB的NAT分配的IPB PORTB,
把双方地址与端口告诉对方，安后ClientA借助服务器通知ClientB 往 ClientA方
向发送UDP包，ClientA 往 ClientB方向发送UDP包，建立连接。
问 客户端在开始连接服务器时是否能使用TCP连接来获得双方的ip和port
...全文
sct 2005年08月24日
//weicf好帖，认真学习
gdy119 2004年12月29日
MSN 是肯定有这个技术了，QQ也有，但知道的人不说 ^_^
aoosang 2004年12月29日
有没有高手解释一下tcp打洞
ywybetter 2004年12月29日
phoenixsharp(小星星)
高人啊
其实我还算是比较理解了
但是我还没有实际测试（靠，俗务缠身啊）
小星星的解释让我了解了P2P的问题是可以实现的
呵呵
多谢高手啦
：）
高人啊
其实我还算是比较理解了
但是我还没有实际测试（靠，俗务缠身啊）
小星星的解释让我了解了P2P的问题是可以实现的
呵呵
多谢高手啦
：）
constants 2004年12月28日
谢谢 楼上几位的解答,我明白了
phoenixsharp 2004年12月28日
TO wenbinmail() :
//你说的也对,不过我的实现不全是你理解的那样:
// 1.具体步骤:[A to S]取第I个好友-->发A上线通知给第I个好友-->好友I发一个包给A--->NEXT;整个取好友的时间如果有一分钟,那末不晓得都取了几千个人回来了,而我用了几秒就取了近百人(每人的资料也不多)
// 2.关于定时检测:这个是必要的,为了维持NAT中的SESSION必须定时发包,一般NAT的失效时间是近两分钟吧,定时检测在线好友:SendHandData(FriendI);sleep(1);这个也不是很吓人啊?!
// 3.关于数据量的问题:定时检测包,我叫它定时握手包,反正就那意思,内容可以只有2个字节,反正作用只是握手(不干别的),应该没有数据量的问题吧?
欢迎讨论。
//你说的也对,不过我的实现不全是你理解的那样:
// 1.具体步骤:[A to S]取第I个好友-->发A上线通知给第I个好友-->好友I发一个包给A--->NEXT;整个取好友的时间如果有一分钟,那末不晓得都取了几千个人回来了,而我用了几秒就取了近百人(每人的资料也不多)
// 2.关于定时检测:这个是必要的,为了维持NAT中的SESSION必须定时发包,一般NAT的失效时间是近两分钟吧,定时检测在线好友:SendHandData(FriendI);sleep(1);这个也不是很吓人啊?!
// 3.关于数据量的问题:定时检测包,我叫它定时握手包,反正就那意思,内容可以只有2个字节,反正作用只是握手(不干别的),应该没有数据量的问题吧?
欢迎讨论。
skfox 2004年12月28日
学习
tangrh 2004年12月28日
一句话，自己的数据包必须在对方数据包到达自己NAT之前通过自己的NAT
wenbinmail 2004年12月28日
不一定需要服务器转发打洞请求
我不认同楼上的说法
A to S: 登录
取好友列表,其中B在线.
发送消息给B,A已经上线啦--->B收到来自S的关于A上线了的通知后,发一个打洞包给A
....
A取完好友列表后,再跟所有在线的兄弟们发一个打洞包,此时应该可以通了.
一个NAT洞一般都有超时问题。
总不可能在没发送信息的时候每隔半分钟，都给所有的好友发送一条信息，然后，所有的好友都在
给自己回应一条信息。这样，如果好友超过20个的话 数据流量就不得了了
我不认同楼上的说法
A to S: 登录
取好友列表,其中B在线.
发送消息给B,A已经上线啦--->B收到来自S的关于A上线了的通知后,发一个打洞包给A
....
A取完好友列表后,再跟所有在线的兄弟们发一个打洞包,此时应该可以通了.
一个NAT洞一般都有超时问题。
总不可能在没发送信息的时候每隔半分钟，都给所有的好友发送一条信息，然后，所有的好友都在
给自己回应一条信息。这样，如果好友超过20个的话 数据流量就不得了了
phoenixsharp 2004年12月28日
第一个理解是错误地,第二个正确,总结成两句话:
都在不同内网的A和B,要想通信,如A想发数据给B,那末必须是B先发数据给A{1}(可以理解为建立一条B to A的通信链路,实际上UDP是无连接的,但重点在网关上--->在NAT的眼里看来,若B先发了数据给A,那末NAT认为是B主动连接外部的A,所以A发数据来时可以让其进入,转给B),当然这时A可能收不到此数据,因为A的网关发现B发来的数据是不请自来的,它心想:万一是什么黑客数据怎么办呢?于是把它KILL掉了{2},好，这个时候A再发数据给B就能通信成功了{3}。
总结成一句话:)
内网的主机想要被别人访问，首先要主动访问别人。~~~南无阿米陀佛~~~~~~~~~~~~~~~~楼上的施主渗透了么~~~~
都在不同内网的A和B,要想通信,如A想发数据给B,那末必须是B先发数据给A{1}(可以理解为建立一条B to A的通信链路,实际上UDP是无连接的,但重点在网关上--->在NAT的眼里看来,若B先发了数据给A,那末NAT认为是B主动连接外部的A,所以A发数据来时可以让其进入,转给B),当然这时A可能收不到此数据,因为A的网关发现B发来的数据是不请自来的,它心想:万一是什么黑客数据怎么办呢?于是把它KILL掉了{2},好，这个时候A再发数据给B就能通信成功了{3}。
总结成一句话:)
内网的主机想要被别人访问，首先要主动访问别人。~~~南无阿米陀佛~~~~~~~~~~~~~~~~楼上的施主渗透了么~~~~
fengge8ylf 2004年12月28日
mark
phoenixsharp 2004年12月27日
QQ传文件就是通过TCP方式(无论你的QQ在哪儿,包括内网,不晓得是如何实现TCP的,UDP倒是比较普遍一点.)
constants 2004年12月27日
我能不能这么理解，A 经过Nat 发包到 B ，期间系统会 在Nat A 建立一个会话 session，假如不经过服务器，A直接发到B，这时B应该是收不到的A发的消息的对么？
如果我人为的控制在A发给B的差不多的时间内B也发给A一个包（或者说在session没有超时的情下（不知道能不能这么理解）），是不是这时候就能建立连接。在往后发就双方都能收到？
如果我人为的控制在A发给B的差不多的时间内B也发给A一个包（或者说在session没有超时的情下（不知道能不能这么理解）），是不是这时候就能建立连接。在往后发就双方都能收到？
oyljerry 2004年12月27日
幸亏现在大多数NAT是cone类型的，要都是symmetric就郁闷了
constants 2004年12月27日
楼上的我能不能这么理解，A 经过Nat 发包到 B ，期间系统会 在Nat A 建立一个会话 session，假如不经过服务器，A直接发到B，这时B应该是收不到的A发的消息的对么？
如果我人为的控制在A发给B的差不多的时间内B也发给A一个包（或者说在session没有超时的情下（不知道能不能这么理解）），是不是这时候就能建立连接。在往后发就双方都能收到？
如果我人为的控制在A发给B的差不多的时间内B也发给A一个包（或者说在session没有超时的情下（不知道能不能这么理解）），是不是这时候就能建立连接。在往后发就双方都能收到？
phoenixsharp 2004年12月27日
其实不一定需要服务器转发打洞请求,俺在做QQ时是这样:
A to S: 登录
取好友列表,其中B在线.
发送消息给B,A已经上线啦--->B收到来自S的关于A上线了的通知后,发一个打洞包给A
....
A取完好友列表后,再跟所有在线的兄弟们发一个打洞包,此时应该可以通了.
所以:打洞包不一定要是S发,但S可以起到一种先后区分的作用,如从宏观上讲,还是S告诉B好友A已上线.
P.S: P2P之完美解决方案望大家多多讨论啊,俺感觉一般的P2P成功太理想化了,NAT类型何其复杂,俺在同一内网时,只因那网关的NAT不支持环回而惨遭洗白,哎,更不用说那些A-->S 和A-->B,NAT会NEW 一下新端口这么喷饭的事了......
A to S: 登录
取好友列表,其中B在线.
发送消息给B,A已经上线啦--->B收到来自S的关于A上线了的通知后,发一个打洞包给A
....
A取完好友列表后,再跟所有在线的兄弟们发一个打洞包,此时应该可以通了.
所以:打洞包不一定要是S发,但S可以起到一种先后区分的作用,如从宏观上讲,还是S告诉B好友A已上线.
P.S: P2P之完美解决方案望大家多多讨论啊,俺感觉一般的P2P成功太理想化了,NAT类型何其复杂,俺在同一内网时,只因那网关的NAT不支持环回而惨遭洗白,哎,更不用说那些A-->S 和A-->B,NAT会NEW 一下新端口这么喷饭的事了......
chengyumao 2004年12月27日
如果只有一方发对方NAT会把这个包拦下来，但如果先往对方地址发一个包，那当对方发来的包到达NAT的时候NAT会认为是对刚才发出的包的回应，从而放行，一个UDP连接就建立起来了。基本上就是这样了。
constants 2004年12月27日
小弟刚看这个跑p2p的程序有点不理解请大家帮忙解释下
ClientA借助服务器通知ClientB 往 ClientA方向发送UDP包,
ClientA 往 ClientB方向发送UDP包，建立连接。
借助服务器通知ClientB 往 ClientA方向发送UDP包
是发到 ClientA的NAT分配的IPA 么？双方都通过服务器获取嘞对方的IP和port，怎么还要通过服务器通知b向a发udp， 跟b直接往a发有什么区别么？
ClientA借助服务器通知ClientB 往 ClientA方向发送UDP包,
ClientA 往 ClientB方向发送UDP包，建立连接。
借助服务器通知ClientB 往 ClientA方向发送UDP包
是发到 ClientA的NAT分配的IPA 么？双方都通过服务器获取嘞对方的IP和port，怎么还要通过服务器通知b向a发udp， 跟b直接往a发有什么区别么？
kingzai 2004年12月26日
你想实现TCP穿透？需要实现一个MIDDLEBOX，csdn 上有一篇BLOG提到过，不过实现起来非常复杂。
aoosang 2004年12月24日
金刚说tcp不行,相关的资料我也不知道