51Testing软件测试论坛

标题: 网络游戏的数据传输处理和防火墙穿透 [打印本页]

作者: 51testing    时间: 2007-11-14 16:05
标题: 网络游戏的数据传输处理和防火墙穿透
一般来说,client和server之间的数据交换,分为几个优先级,大部分情况下是下面3种:
1. 不可以丢失,但是不要求速度。
2. 不可以丢失,但是要求速度,确并不是非常严格。
3. 可以丢失,但是要求速度    对于1来说,最直接的例子就是聊天信息,动态的地图信息。这些数据不是time-critical的,所以应该使用TCP连接。 在大多数情况下,有专门的  voice/chat server和map server,client到每个server有个TCP连接。一个client有多少个连接根据需要决定。同时有2-3个连接并没有多大开销。当然,如果开销很大,就是程序设计的问题了。其实你想想开BT的时候同时有4,50个连接,你用其他程序的速度并没有慢多少。
    对于2来说,比较显著的例子是战斗信息,动作序列。 比如一个人玩游戏,用鼠标点了下地图上的一个坐标,那么些人物向这个坐标前进。这个信息从server转发到其他的client,当然越快越好,如果client没收到,就要重发,否则client就看不到这个动作。如果你玩过wow的盗贼,就会发现在网络卡的时候,经常先偷袭,按下键盘以后要等一会才看到攻击动作,就是这个原理。当然这里数据需要经过server的处理,每次打包多个client的动作,和顺序,然后发送。需要复杂的server端逻辑处理。这种应该使用UDP,同时对所有的UDP包编号(用来防止2次处理),使用slide window类似的协议进行重传。
    对于3来说,就是位置信息。 位置信息可以丢失,但是由于这种信息更新的最频繁,所以即使丢失其中一个,也可以根据 dead reckoning 算法进行位置预测和修正。 dead reckoning算法有很多变种,适合多类情况。 比如你见过wow里,如果一个人掉线,但是一直往前不停的跑,那多半就是算法进行的预测。偶尔你会发现网络卡的时候,刚刚走到一个地方就退回到原来的位置,就是因为你的动作数据包(2里的)没发送出去,导致update world position的时候,算法进行位置修正的结果。这类数据应该使用UDP.
    需要说明的是 UDP和TCP无明显分界。 TCP相比UDP,只有3个缺点,1是slow start, 2是 throughput jitter, 3是insistence on reliability(相对的,不时绝对缺点). 在数据传诵量比较小,网络状况比较稳定的情况下,使用TCP和UDP无大分别。

    对于防火墙穿透,如果你是做client的,不需要关心这个问题,因为你往Server发数据,建立连接,都不会受到放火墙的影响。不过server端对于放火墙可以有几种实现方式:
1. 最差的方式是client发送SYN包给服务器,在防火墙或网关上建立NAT地址,然后 Server之需要取得这个NAT地址,把所有的数据包都封装成SYN-ACK包,发给client就行拉。这样做比较省事。但是无法穿透 stateful firewall
2. 是比较好的方式。 不过需要先建立TCP连接,然后对server发送正常的UDP包。大部分的NAT网关会为UDP专门建立个NAT地址,那么通过这个地址,server就可以发UDP包了。但是并不是所有的firewall都会为UDP建立单独的NAT地址。
3.  是最好的方式,由于防火墙不会阻止内部网发起的TCP连接,所以TCP进行数据传输没有任何问题。对于Server/Client来说,只要使用 Raw Socket模拟TCP协议,但是这个模拟的TCP协议使用UDP的本质,没有slide window, 没有 congestion control, 没有flow control等等,这种实现最麻烦,但是几乎能处理所有的防火墙。
4. 其实没有4,不过实在想提下这种最强技术. 就是所有的Server到Client的数据包都可以是ICMP echo reply message. 由于种种原因,firewall不太可能禁止ICMP echo,所以这类消息也是很容易传送到client,但是。。。。。。。。Client如果有 IDS system,很容易把你的sever归类到入侵扫描的范围。所以不用最好。
    如果你们不是采用第3种方式,并且你只写client,那么防火墙跟你就没有什么关系。都是server的事。




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2