原文版權：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方式支持控制報文和媒體流的加密，因此安全性比較高。