Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
A-B 155.99.25.11:62001 B-A 138.76.29.7:31001
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
显而易见有很多情况都能导致这种方法失败。假如任意一个预测的端口碰巧已经被其他无关的连接占用,NAT将会错过正确的端口,连接尝试也将失败。假如任意一个NAT有时或者总是选择非连续的端口号,这个方法也将失败。假如在A(B)建立了它和S的连接之后,但在发送第一个数据包到B(A)之前,一个不同的客户端在NAT(也或者B)打开一个新的外部连接到任何外部主机,无关的客户端会不注意的"偷"了(A TO B或者B TO A)所要求的端口。因此在任一NAT都包含不止一台客户端时,这种方法很少使用。
实际上,如果那些NAT是cone NAT,或者一个是cone NAT,另一个是对称NAT,这种情况下的P2P应用程序依然需要工作,应用程序需要实现查明在任何一个上与end [STUN]有关的NAT是哪一钟,并按此来修改它的工作方式,这样增加了算法的复杂程序并让网络变的脆弱。最终,假如任何一方客户端在2级以上的NAT下并且离客户端最近的NAT是对称的,预测端口的方式是无法工作的。对所有这些原因来说,应用程序是无法实现这种方法的,在这里被提及是为了历史和信息目的(就是告诉大家有这么回事,我想)