2012-06-18

昨天了解到一个自己不知道的东西，毕竟游戏没有这种应用场景，所以看看资料，UDP如何实现打洞实现P2P？

关键词：UDP, NAT

应用场景：

第一种场景，我们假设两个客户端都处于不同的NAT之后；

第二种场景，我们假设两个客户端都处于同一个NAT之后，但是它们彼此都不知道(他们在同一个NAT中)。

NAT的类型：

1 -Full Cone ，这种NAT内部的机器A连接过外网机器C后,NAT会打开一个端口.然后外网的任何发到这个打开的端口的UDP数据报都可以到达A.不管是不是C发过来的.

    对于这种模式的不需要做打洞就能直接通信了

2 -Restricted Cone，这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用任何端口和A通信.其他的外网机器不行.

3 -Port Restricted Cone，这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用原来的端口和A通信.其他的外网机器不行.

4 -Symmetric，对于这种NAT.连接不同的外部目标.原来NAT打开的端口会变化.

 

总结

对于第一种场景来说，工作原理大致为：

公网server作为P2P协调，交换A和B的ip和port，

A和B通过对方的地址信息，通过udp进行发送数据包（告知双方NAT数据包可转发到本机）

即打洞成功，可以开始通信

 

对于第二种场景来说，工作原理大致为：

如果有多层NAT，则无法使用比较外网IP和内网IP的方法来确认A和B是否在用一NAT下，难道只能判断可能在同一NAT，然后做“尝试握手”?

 

另外，还需要做的两点是，

1.判断主机是否处于NAT下

a)可比较主机和本地地址和公网地址来判断

2.判断NAT的类型，然后来处理业务

a)根据NAT的特性来握手判断

 

备注问题

a)当NAT为Symmetric，实现打洞很困难，基本不考虑

b)当NAT为Port Restricted Cone模式，会出现一个问题

不同的IPC使用的UDP port 可能为重复的，集中监控客户端将以相同的端口来和很多IPC通信，会不会出问题呢？测试一下吧，以前用UDP的时间比较少。

 

 

UPNP

终于搞通了，局域网组播地址依然是：239.255.255.250:1900

sniff只能检测本地网卡的数据包，所以必须要把IPC插到网卡上看，放在局域网没用。还有IPC的UPNP发布时间为3秒间隔

 

CALL

M-SEARCH * HTTP/1.1
HOST:239.255.255.250:1900
ST:upnp:rootdevice
Man:"ssdp:discover"
MX:3

 

BACK

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
DATE: Thu, 01 Jan 1970 02:27:17 GMT
EXT:
LOCATION: http://192.168.1.90:49152/iftcdevicedesc.xml
SERVER: Linux/2.6.28, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
X-User-Agent: redsonic
ST: upnp:rootdevice
USN: uuid:Upnp-Camera-1_0-000C0CA07911::upnp:rootdevice

 

keyword:

iftcdevicedesc.xml,可分析次字段来获取ip地址