如何测试您的客户端服务器程序

Question

我正在制作一个多人游戏，并且经常想测试它是否可以在全球网络上正常运行，因为有时它只能在本地运行，所以我怎么能做到这一点而无需将客户发送给朋友进行测试。

Answer 1

If you want to test it for the "global network" - you have to test it that way. There are multiple things that can go wrong which are not an issue on a local network. Just off the top of my head

1. latency (important for a game)
2. NAT (common cause of problems depending on your game architecture - more so if P2P)
3. security
4. connection errors (Wifi/3G intermittent loss)

Answer 2

There are many aspects of networking that are often subtly different when you're talking over the internet rather than running on either localhost or a local network.

• All manner of delays can occur, and this can throw out some poor assumptions in your code.
• The TCP flow can be affected by TCP's flow control (when the TCP Window fills up the sender will stop sending and report the fact to you (or maybe not report it, if you're using async APIs)).
• TCP reads that return 'complete messages' on localhost and your own network may start to return pieces of a message.
• UDP datagrams may go missing and never arrive or may arrive multiple times or in any sequence.

So you're right to think that you need to test your code for these edge cases which rarely show up on your own network. You're also right to think that simply sending a client to a friend, or running it on a remote machine, is not enough.

One approach is to build a dedicated test client which sends known game play and checks that it gets expected responses (how hard this is depends on your protocol and your game). Once you have that working you then have the test client deliberately send data in such a way that the items above are tested. So, if you're using UDP, you might put some code in your test client so that it sometimes doesn't bother to send a UDP datagram at all. The client should think it sent it. The networking layer simply ditches it. This tests your UDP protocol for missing datagrams. Then send some datagrams multiple times, then send some out of sequence, etc. For TCP add delays, break logical "messages" into separate network sends with large delays between them; ideally send each distinct message type as a sequence of single bytes to check that the server's 'message accumulation code' works correctly.

Once you have done this you need to do the same for your client code, perhaps by adding a "fuzzing" option to your server's network code to do the same kind of thing...

Personally I tend to try and take a step back and do as much of this as possible in dedicated 'unit tests' (I know that some people will say that these aren't unit tests, call them what you like, just write them!). These tests exercise your networking layer using real networking (talking to a dummy server/client that the test creates) and validate the horrible edge cases.