hxh(贺星河)的专栏

看美人颜红,心窃喜;纵有来生复世,知己难求;且饮酒西楼,把江山灌醉,莫问心忧!

用户操作
[即时聊天] [发私信] [加为好友]
贺星河ID:hxhbluestar
97483次访问,排名927好友0人,关注者4
hxhbluestar的文章
原创 28 篇
翻译 7 篇
转载 5 篇
评论 73 篇
贺星河的公告

>>贺星河的新浪博客<<

>>贺星河的博客园博客<<

最近评论
sap99:www.sap99.com/,SAP99资料多多

SAP免费资料下载
http://www.sap99.com

有很多的学习资料,推荐一下,
zhihui708:如何新建那个WeatherDataSet.XSD文件,是不是添加一个“XML 架构”啊
dxshenhua:我已经实现了TCP-P2P直连,包括自动识别两个用户中有一个是公网用户,两个用户在同一个局域网,两个不同内网用户的穿透直连。
caoyuan85:学习。。。。。。。
ys19011:hxh:
没有看清表述,现在理解了。全Cone、一Cone一symmetric、全在NAT后、部分NAT在、都不在NAT后确实走的是一样的流程。
文章分类
收藏
相册
SmartPhone
WebService
文章图片
我的照片
.Net
C# - OpenGL
C# Friends
C# Helper
C# Home
Codeproject
Dotnet2themax 框架库
Gotdotnet
OpenNETCF.org - Source
VS.NET2003
Windows Forms
Java
Calvin Austin J2SE5.0(RSS)
Java.net
JavaWorld
Java官方
JXTA P2P
VC++
JIURL's Doc
XML
中国XML论坛
安全专题
小榕软件实验室
网络安全焦点
帮助文档
IBM中文开发者网站
MSDN中文网
MSDN在线文档
MS搜索知识库
W3C中文翻译
操作系统
Longhorn
高级战友
AOL(RSS)
XML MVP
孟子E章
思归呓语
解决方案
Duwamish解决方案
权威站点
ACE
Linux
Python
RFC
SourceForge
UML
W3C
Web Services(RSS)
XML
设计模式
Design Patterns
Patterns in Java
项目管理
CVS
WorldHello
友情链接
CoolBug
Johnson
林星
海华
热闹城市-市长日记
祖尔谈软件
存档
软件项目交易
订阅我的博客
XML聚合  FeedSky
订阅到鲜果
订阅到Google
订阅到抓虾
订阅到BlogLines
订阅到Yahoo
订阅到GouGou
订阅到飞鸽
订阅到Rojo
订阅到newsgator
订阅到netvibes

翻译 Peer-to-Peer (P2P) communication across middleboxes(翻译2) 收藏

新一篇: Peer-to-Peer (P2P) communication across middleboxes(翻译3)  | 旧一篇: Peer-to-Peer (P2P) communication across middleboxes(翻译1)

原文版权:Copyright (C) The Internet Society (2003).? All Rights Reserved.

原文地址:http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

译文版权申明:请引用此文的作者或网站注明出处:http://blog.csdn.net/hxhbluestar,以尊重译者的劳动成果!

 

 

3.3. UDP hole punching  UDP打洞技术

    The third technique, and the one of primary interest in this document, is widely known as "UDP Hole Punching." UDP hole punching relies on the properties of common firewalls and cone NATs to allow appropriately designed peer-to-peer applications to "punch holes" through the middlebox and establish direct connectivity with each other, even when both communicating hosts may lie behind middleboxes. This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and has been informally described elsewhere on the Internet [KEGEL] and used in some recent protocols [TEREDO, ICE]. As the name implies, unfortunately, this technique works reliably only with UDP.

 

    第三种技术,也是这篇文章主要要研究的,就是非常有名的“UDP打洞技术UDP打洞技术依赖于由公共防火墙和cone NAT,允许适当的有计划的端对端应用程序通过NAT打洞,即使当双方的主机都处于NAT之后。这种技术在 RFC30275.1[NAT PROT] 中进行了重点介绍,并且在Internet[KEGEL]中进行了非正式的描叙,还应用到了最新的一些协议,例如[TEREDO,ICE]协议中。不过,我们要注意的是,如其名,UDP打洞技术的可靠性全都要依赖于UDP

 

     We will consider two specific scenarios, and how applications can be designed to handle both of them gracefully. In the first situation, representing the common case, two clients desiring direct peer-to- peer communication reside behind two different NATs. In the second, the two clients actually reside behind the same NAT, but do not necessarily know that they do.

 

     这里将考虑两种典型场景,来介绍连接的双方应用程序如何按照计划的进行通信的,第一种场景,我们假设两个客户端都处于不同的NAT之后;第二种场景,我们假设两个客户端都处于同一个NAT之后,但是它们彼此都不知道(他们在同一个NAT)

 

3.3.1. Peers behind different NATs  处于不同NAT之后的客户端通信

 

     Suppose clients A and B both have private IP addresses and lie behind different network address translators. The peer-to-peer application running on clients A and B and on server S each use UDP port 1234.? A and B have each initiated UDP communication sessions with server S, causing NAT A to assign its own public UDP port 62000 for A's session with S, and causing NAT B to assign its port 31000 to B's session with S, respectively.

 

    我们假设 Client A 和 Client B 都拥有自己的私有IP地址,并且都处在不同的NAT之后,端对端的程序运行于 CLIENT A,CLIENT B,S之间,并且它们都开放了UDP端口1234 CLIENT ACLIENT B首先分别与S建立通信会话,这时NAT A把它自己的UDP端口62000分配给CLIENT AS的会话,NAT B也把自己的UDP端口31000分配给CLIENT BS的会话。如下图所示:

     Now suppose that client A wants to establish a UDP communication session directly with client B.? If A simply starts sending UDP messages to B's public address, 138.76.29.7:31000, then NAT B will typically discard these incoming messages (unless it is a full cone NAT), because the source address and port number does not match those of S, with which the original outgoing session was established. Similarly, if B simply starts sending UDP messages to A's public address, then NAT A will typically discard these messages.

 

     假如这个时候 CLIENT A 想与 CLIENT B建立一条UDP通信直连,如果 CLIENT A只是简单的发送一个UDP信息到CLIENT B的公网地址138.76.29.7:31000的话,NAT B会不加考虑的将这个信息丢弃(除非NAT B是一个 full cone NAT),因为 这个UDP信息中所包含的地址信息,与CLIENT B和服务器S建立连接时存储在NAT B中的服务器S的地址信息不符。同样的,CLIENT B如果做同样的事情,发送的UDP信息也会被 NAT A 丢弃。

 

     Suppose A starts sending UDP messages to B's public address, however, and simultaneously relays a request through server S to B, asking B to start sending UDP messages to A's public address.? A's outgoing messages directed to B's public address (138.76.29.7:31000) cause NAT A to open up a new communication session between A's private address and B's public address. At the same time, B's messages to A's public address (155.99.25.11:62000) cause NAT B to open up a new communication session between B's private address and A's public address. Once the new UDP sessions have been opened up in each direction, client A and B can communicate with each other directly without further burden on the "introduction" server S.

 

    假如 CLIENT A 开始发送一个 UDP 信息到 CLIENT B 的公网地址上,与此同时,他又通过S中转发送了一个邀请信息给CLIENT B,请求CLIENT B也给CLIENT A发送一个UDP信息到 CLIENT A的公网地址上。这时CLIENT ACLIENT B的公网IP(138.76.29.7:31000)发送的信息导致 NAT A 打开一个处于 CLIENT A的私有地址和CLIENT B的公网地址之间的新的通信会话,与此同时,NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了,CLIENT ACLIENT B之间就可以直接通信,而无需S来牵线搭桥了。(这就是所谓的打洞技术)!

 

     The UDP hole punching technique has several useful properties. Once a direct peer-to-peer UDP connection has been established between two clients behind middleboxes, either party on that connection can in turn take over the role of "introducer" and help the other party establish peer-to-peer connections with additional peers, minimizing the load on the initial introduction server S. The application does not need to attempt to detect explicitly what kind of middlebox it is behind, if any [STUN], since the procedure above will establish peer- to-peer communication channels equally well if either or both clients do not happen to be behind a middlebox.? The hole punching technique even works automatically with multiple NATs, where one or both clients are removed from the public Internet via two or more levels of address translation.

 

     UDP打洞技术有很多实用的地方:第一,一旦这种处于NAT之后的端对端的直连建立之后,连接的双方可以轮流担任 对方的媒人,把对方介绍给其他的客户端,这样就极大的降低了服务器S的工作量;第二,应用程序不用关心这个NAT是属于cone还是symmetric,即便要,如果连接的双方有一方或者双方都恰好不处于NAT之后,基于上叙的步骤,他们之间还是可以建立很好的通信通道;第三,打洞技术能够自动运作在多重NAT之后,不论连接的双方经过多少层NAT才到达Internet,都可以进行通信。

 

 

译后小记:本来已经翻译好了,是在网文快捕中翻译的,结果,一个全选把所有翻译的内容全部删除了(网文快捕的Bug?:),不得不痛苦的再翻一遍。不过,有失必有得,第二次翻译流畅多了,希望大家读来还顺口。

发表于 @ 2004年09月12日 23:09:00|评论(loading...)|编辑

新一篇: Peer-to-Peer (P2P) communication across middleboxes(翻译3)  | 旧一篇: Peer-to-Peer (P2P) communication across middleboxes(翻译1)

评论

#KEVIN 发表于2004-09-13 13:30:00  IP: 61.51.143.*
太难了,能给出一些代码吗?
#hxh 发表于2004-09-14 09:08:00  IP: 218.81.104.*
在翻译完主要文章后,如果有时间的话,我会写一个比较完整的实例(用C#),但愿我不食言,呵呵。

#hxh 发表于2004-09-29 20:10:00  IP: 218.81.113.*
3X,这段时间比较忙,所以暂时没有时间翻译了,请见谅:)
#LanSea 发表于2004-11-12 09:42:00  IP: 218.16.76.*
你这个UDP打洞技术思想确实不错,确实是实现点到点通信的好办法。
#hxh 发表于2004-11-12 14:15:00  IP: 218.81.117.*
呵呵,这个不是我的思想,前辈们早就提出解决方案了:)
#ray lynn 发表于2005-09-05 11:04:00  IP: 211.100.21.*
假如 CLIENT A 开始发送一个 UDP 信息到 CLIENT B 的公网地址上,与此同时,他又通过S中转发送了一个邀请信息给CLIENT B,请求CLIENT B也给CLIENT A发送一个UDP信息到 CLIENT A的公网地址上。这时CLIENT A向CLIENT B的公网IP(138.76.29.7:31000)发送的信息导致 NAT A 打开一个处于 CLIENT A的私有地址和CLIENT B的公网地址之间的新的通信会话,与此同时,NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了,CLIENT A和CLIENT B之间就可以直接通信,而无需S来牵线搭桥了。(这就是所谓的打洞技术)!




--------------------
这里不解:
与此同时,他又通过S中转发送了一个邀请信息给CLIENT B

在这之前CLIENT B必须与S建立会话吧?
#xiao_fang 发表于2006-03-09 14:09:00  IP: 211.140.10.*
to ray lynn:
这里的前提是client a/b都已先连接到服务器s
#ys19011 发表于2007-04-12 11:30:42  IP: 172.17.85.*
to hxh:
你好,文中:“第二,应用程序不用关心这个NAT是属于cone还是symmetric,即便要,如果连接的双方有一方或者双方都恰好不处于NAT之后,基于上叙的步骤,他们之间还是可以建立很好的通信通道;”
请解释一下,看过前文后,觉得应该是很受NAT类型的影响的!谢谢!
#ys19011 发表于2007-04-12 13:01:55  IP: 172.17.85.*
hxh:
没有看清表述,现在理解了。全Cone、一Cone一symmetric、全在NAT后、部分NAT在、都不在NAT后确实走的是一样的流程。
发表评论  


当前用户设置只有注册用户才能发表评论。如果你没有登录,请点击登录
Csdn Blog version 3.1a
Copyright © 贺星河