Subj. There is very little argument that such testing is absolutely necessary for network games, but exact tools vary significantly. Of special interest are tools (if there are any) which can be set up on a developer's laptop (without the need to have a dedicated testing box). All the information (especially personal experiences like "using this tool, works well") will be REALLY appreciated.
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
What are you guys using to simulate packet loss/latency while testing?
This tool works fairly well:
https://www.softperfect.com/products/connectionemulator/
It does not allow you to mess with the loopback interface though, so you basically have to have two boxes (or two physical network interfaces). Some people build this sort of thing right into their network layer. That way you don't need any separate software at all.
EDIT: I almost forgot. There is this thing as well: https://github.com/jagt/clumsy I have not used it though.
Current company uses Charles proxy:
https://www.charlesproxy.com
previous company used to use Shunra which is now owned by HP:
http://www8.hp.com/uk/en/software-solutions/network-virtualization/
We've generally used various proxies, the connection emulator above is one of them. On occasion we had a separate hub where the machines were on their own little network and a PC served as the packet-corrupting bridge between networks.
I've also seen both setups as seen above. One has all the machines on their own private switch attached to a PC through a secondary network port and that PC coordinates the delays, other times the test boxes are just pointed to the ip address of the proxy, Both work, depending on the needs your software has.
I've also seen both setups as seen above. One has all the machines on their own private switch attached to a PC through a secondary network port and that PC coordinates the delays, other times the test boxes are just pointed to the ip address of the proxy, Both work, depending on the needs your software has.
A Google will find several tools, and they are all OK.
Personally, I prefer to put the control in right at the in-app network layer.
The benefit is that you can at that point even write unit tests around failure cases!
Assuming you're using UDP, easiest is to wrap sendto(), and take one of a few actions:
- send the packet
- put a copy of the packet in a delay/re-order/replica queue
- send some other packet from the delay/re-order/replica queue
- drop the packet (happens if you don't send it or replicate it)
Note that you typically want to do anywhere between zero and three of those things at the same time!
If you want to test in production without hurting other users' experience too badly, you can also implement similar shenanigans in your wrapper for recvfrom(), which allows you to inject a "bad" view into one particular client.
Personally, I prefer to put the control in right at the in-app network layer.
The benefit is that you can at that point even write unit tests around failure cases!
Assuming you're using UDP, easiest is to wrap sendto(), and take one of a few actions:
- send the packet
- put a copy of the packet in a delay/re-order/replica queue
- send some other packet from the delay/re-order/replica queue
- drop the packet (happens if you don't send it or replicate it)
Note that you typically want to do anywhere between zero and three of those things at the same time!
If you want to test in production without hurting other users' experience too badly, you can also implement similar shenanigans in your wrapper for recvfrom(), which allows you to inject a "bad" view into one particular client.
Author
Thanks a lot guys, will take a closer look at the tools you've mentioned... Also - does anybody have any practical experience with netem?
Personally, I prefer to put the control in right at the in-app network layer.
The benefit is that you can at that point even write unit tests around failure cases!
Assuming you're using UDP, easiest is to wrap sendto(), and take one of a few actions:
That's what I personally prefer myself too, but way too often I'm running into resistance on this way :-( . The second issue is that for testing of TCP fallback it won't work :-( . Currently I'm thinking about creating a Linux VM image with netem within (and it is already compiled in by most distros) and using it as a kind of simulating router, but wondering whether there are any better/more-widely-used options.
If you want to test in production without hurting other users' experience too badly, you can also implement similar shenanigans in your wrapper for recvfrom(), which allows you to inject a "bad" view into one particular client.
Good one, thanks, didn't think about it myself...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
