• Advertisement
Sign in to follow this  

Looking to test lag/packetloss/corruption

This topic is 1681 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'd like to perform network tests on my game in the most realistic way possible. This means having to deal with players who are on crappy wireless connections, who might even be playing on cellphones.

 

Short of having a friend living in a far away country with a copy of the game and a cellphone testing platform, what's a good way to stress-test your networking gudgeons?

 

Are there virtual Ethernet adaptors that can be configured to drop a percentage of packets, corrupt them, delay them, send them out-of-order?

Maybe some sort of firmware that can be loaded onto an external router which would sit in between two testing machines?

 

And, is there any sort of standard for robustness that I should aim for, like supporting 300ms ping delays, 30% packet loss before things go wonky, dealing with timeouts, etc?

Share this post


Link to post
Share on other sites
Advertisement

Hmm. Looks like I might be able to set up my spare netbook with Ubuntu and turn it into a router and run Netem on it.

Share this post


Link to post
Share on other sites

One trick I have used is to write a thin layer over the socket API, and provide pluggable functionality to simulate packet loss/ordering at that level. Effectively, the sending side socket will elect to either discard or delay a configurable percentage of all packets, at random.

 

It seemed to do a pretty good job at the time. Of course, it only works for UDP, since TCP handles packet loss at a much lower level.

Share this post


Link to post
Share on other sites

Both options are good:

1) Run a Linux something-or-other, either as a gateway, or for the actual server, with an error injector.

2) Add a thin layer on top of your networking that supports fuzz testing in various ways. Even for TCP, this can be useful, as it can emulate high latency, slow throughput, etc.

 

In addition, if you're serious about this, I would suggest:

3) Rent a VPN connection in some other country, and test while connected through that. Because one kind of VPN user is Bittorrent users who have high bandwidth, those generally provide pretty terrible performance, so that's a great stress test!

Share this post


Link to post
Share on other sites

Why not just have the real thing? If you have a router, move it farther and farther away until the connection becomes highly unstable, which means you are at the very edge of its emission range (it fluctuates randomly). Voilà. This is as real as it gets and is how "players with crappy wireless networks" are actually going to use your software wink.png

Share this post


Link to post
Share on other sites

Just go to the local Starbucks at prime time.  Half of them still have decent performance but I find when there are 15+ people I often see packet loss spike from 0/1% to 5-15% and latency spike from 150 to 300-2000.

Share this post


Link to post
Share on other sites

Consider setting up a Linux box as your network router, and use netem (successor to NistNET) to cause network disruption.

 

The other alternative, if you are writing your own network code, is to put a debug only path in that lets you cause artificial failure conditions, limit bandwidth, and so on.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement