原文版权：Copyright (C) The Internet Society (2003).? All Rights Reserved.
原文版权：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，以尊重译者的劳动成果！
4. Application design guidelines
4.程序设计指南
4.1. What works with P2P middleboxes
4.1. P2P代理的现状
对于两端都处于NAT之后的P2P直连，当前最佳解决方案仍然是UDP打洞技术，而在各种NAT系统中这种技术也得到了相当广泛的应用。当程序需要进行有效的p2p直连的通讯时候，推荐使用UDP打洞技术，当然，当无法建立直连时，也要做好消息转发的处理。
Since UDP hole punching is the most efficient existing method of establishing direct peer-to-peer communication between two nodes that are both behind NATs, and it works with a wide variety of existing NATs, it is recommended that applications use this technique if efficient peer-to-peer communication is required, but be prepared to fall back on simple relaying when direct communication cannot be established.
4.2. Peers behind the same NAT
4.2. 位于同一个NAT后的端与端通信指南
在实际的情况中，还有相当大一部分用户不止两个IP地址（多网卡情况），而是三个或者更多，这种情况下，如果很难决定到底使用哪个地址来注册到服务器，就要应用程序将所有的地址都注册到服务器上去。
In practice there may be a fairly large number of users who have not two IP addresses, but three or more. In these cases, it is hard or impossible to tell which addresses to send to the registration server. The applications should send all its addresses, in such a case.
4.3. Peer discovery
4.3. 主机发现
应用程序发送很多包到网络的几个地址上，用于发现哪个地址对于指定的主机来说是最好的。这样是导致网络“空间浪费”的源头之一，就象是在网络上倒垃圾一样；端将会选择不正确的路由地址；就像在内部网中一样（例如：11.0.1.1，分配给DOD [DOD还不能确定是什么，查到相关文献是与美国国防部相关的协议] 的）;因此应用程序在发送hello包时，应该小心地练习。(这段话翻译得不是很好，请求指正)
Applications sending packets to several addresses to discover which one is best to use for a given peer may become a significant source of 'space junk' littering the net, as the peer may have chosen to use routable addresses improperly as an internal LAN (e.g. 11.0.1.1, which is assigned to the DOD). Thus applications should exercise caution when sending the speculative hello packets.
4.4. TCP P2P applications
4.4. 基于TCP 的P2P应用程序
套接字API被应用程序开发者广泛地使用，但它其实最初是专门设计用于 C/S模式的应用程序的。由于这个自身原因，就出现了一些限制：一个套接字只能绑定一个TCP或者UDP端口；应用程序不允许多个套接字绑定同一个端口（TCP或UDP）用于同时与多个外部节点建立会话；也不允许使用一个套接字来监听这个端口的同时，其他套接字通过这个端口发出向外的初始化会话连接。
The sockets API, used widely by application developers, is designed with client-server applications in mind. In its native form, only a single socket can bind to a TCP or UDP port. An application is not allowed to have multiple sockets binding to the same port (TCP or UDP) to initiate simultaneous sessions with multiple external nodes (or) use one socket to listen on the port and the other sockets to initiate outgoing sessions.
上面所说的“单一套接字对应单一端口”绑定约束对于UDP来说并不算一个障碍，因为UDP是一个基于数据报的协议。UDP P2P应用程序设计者可以用recvfrom()和sendto()函数来让一个SOCKET不仅发送而且可以从多个主机上接受数据报文。
The above single-socket-to-port bind restriction is not a problem however with UDP, because UDP is a datagram based protocol. UDP P2P application designers could use a single socket to send as well as receive datagrams from multiple peers using recvfrom() and sendto() calls.
但是TCP就不一样了。TCP中，每个进入和外出的连接都和一个单独的套接字保持关联。Linux 套接字API中使用 SO_REUSEADDR 选项标记了这个问题。在FreeBSD和NetBSD上，这个选项一般来说是无法正常工作的，但是，可以将其改为使用BSD-specific SetReuseAddress call(Linux中并没有这个命令，纯Unix标准中亦不存在），就可以使用了。Win32 API提供了一个等效的SetReuseAddress 命令。使用以上所提到的选项，应用程序就能使用多个套接字用来重用TCP端口。那就是说，打开两个TCP套接字流绑定使用同一个端口，只要使用listen()在一边并在另外一边使用connect()在另外一端。
This is not the case with TCP. With TCP, each incoming and outgoing connection is to be associated with a separate socket. Linux sockets API addresses this problem with the aid of SO_REUSEADDR option. On FreeBSD and NetBSD, this option does not seem to work; but, changing it to use the BSD-specific SetReuseAddress call (which Linux doesn't have and isn't in the Single Unix Standard) seems to work. Win32 API offers an equivalent SetReuseAddress call. Using any of the above mentioned options, an application could use multiple sockets to reuse a TCP port. Say, open two TCP stream sockets bound to the same port, do a listen() on one and a connect() from the other.
4.5. Use of midcom protocol
4.5. 使用 MidCom 协议
如果应用程序知道它们需要穿越的代理并且这些代理实现Midcom协议，应用程序能使用Midcom协议更容易的穿越代理。
If the applications know the middleboxes they would be traversing and these middleboxes implement the midcom protocol, applications could use the midcom protocol to ease their way through the middleboxes.
例如：P2P应用程序需要NAT代理保持终端端口的绑定状态。假如代理可以支持Midcom，P2P应用程序可以控制修改绑定端口(或者绑定地址)的参数，例如生存时间，最大空闲时间，因此应用程序不仅可以直接的连接外部主机而且也可以从外部主机接受连接；这样就不需要定期保持端口绑定的状态。当应用程序不再需要绑定，也可以使用Midcom协议简单的取消绑定。
For example, P2P applications require that NAT middleboxes preserve end-point port bindings. If midcom is supported on the middleboxes, P2P applications can exercise control over port binding (or address binding) parameters such as lifetime, maxidletime, and directionality so the applications can both connect to external peers as well as receive connections from external peers; and do not need to send periodic keep-alives to keep the port binding alive. When the application no longer needs the binding, the application could simply dismantle the binding, also using the midcom protocol.
参考：MidCom方案
MidCom（Middlebox Communications）方案是通过在第三方实体和FW/NAT之间建立中间盒来通信，使FW/NAT设备变为可控的一种新的概念。如图所示，MidCom包括MidCom Agent和Middlebox，Agent通过MidCom协议通知Middlebox建立相应的NAT映射表项。
一般情况下，Middlebox集成在NAT或FW设备中，Agent可在软交换、代理服务器或终端上实现。
由于应用业务识别的智能从Middlebox移到外部的MidCom Agent上，因此，根据MidCom的架构，在不需要更改Middlebox基本特性的基础上，通过对MidCom Agent的升级就可以支持更多的新业务。这是相对于NAT/ALG方式的一个很大的优势。
从安全性考虑，MidCom方式支持控制报文和媒体流的加密，因此安全性比较高。