Jump to content

  • Log In with Google      Sign In   
  • Create Account


Looking to test lag/packetloss/corruption


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 lemec   Members   -  Reputation: 105

Like
0Likes
Like

Posted 12 June 2013 - 07:42 PM

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?



Sponsor:

#2 lemec   Members   -  Reputation: 105

Like
1Likes
Like

Posted 12 June 2013 - 07:56 PM

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.



#3 swiftcoder   Senior Moderators   -  Reputation: 9510

Like
2Likes
Like

Posted 12 June 2013 - 11:38 PM

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.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#4 hplus0603   Moderators   -  Reputation: 4904

Like
1Likes
Like

Posted 13 June 2013 - 10:31 AM

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!


enum Bool { True, False, FileNotFound };

#5 Bacterius   Crossbones+   -  Reputation: 7975

Like
0Likes
Like

Posted 15 June 2013 - 02:05 AM

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


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#6 starbasecitadel   Members   -  Reputation: 694

Like
0Likes
Like

Posted 15 June 2013 - 11:37 AM

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.



#7 Dave Weinstein   Members   -  Reputation: 462

Like
0Likes
Like

Posted 15 June 2013 - 02:40 PM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS