Best way to simulate a MultiplayerGame over internet in a LAN?
Author
Before I test over the internet (still fixing bugs) I want to do some test over the LAN. But what's the best or most realistic way to simulate?
Should I simply lower the framerate of the game?
Because If I would play against someone with a very slow connection I'm unsure what I will encounter. Packet drops is pretty easy to simulate. Also how should I simulate latency? I use UDP-only. How do I simulate bandwidth?
What I did for Star Wars : Rebellion was do have a layer that took all packets to or from the network, queued them up, and then could apply several transforms to them.
For instance, you could set a minimum additional latency, so that each packed that arrived would never be forwarded to its destination object until at least 500 msecs had passed. Plus there was a latency variation factor as well.
I also added a random chance of duplicating, dropping a packet, or shifting packet order.
This was a fun little project, and allowed me to debug a de-sync problem happening over the internet, by using 2 local machines. All I did was increase the latency to 800 msecs, and the problem showed up right away.
Another option would be corrupt packets ( which you could detect with a crc ).
For instance, you could set a minimum additional latency, so that each packed that arrived would never be forwarded to its destination object until at least 500 msecs had passed. Plus there was a latency variation factor as well.
I also added a random chance of duplicating, dropping a packet, or shifting packet order.
This was a fun little project, and allowed me to debug a de-sync problem happening over the internet, by using 2 local machines. All I did was increase the latency to 800 msecs, and the problem showed up right away.
Another option would be corrupt packets ( which you could detect with a crc ).
Author
@ Crawl - NetLimitier is great to test with reduced bandwith (solves that problem), but how does it really work - What does it do? It works but it's kinda strange. Very cool that you also can measure your network traffic this way. How do you use it when you use it to test?
@ SimmerD - Sounds like a smart way. The problem with layers is that I have idea what it is in programming, unless we're talking FLASH ;)
Do you mean I make an external application which intercept the messages? When I send a udp message it's gone as far as I know. Can I intercept it?
Or do you mean I should do it in the app; put all to-be-sent messages in a Latency List? Because that would probably work now when I think about it. Was that how you did it?
@ SimmerD - Sounds like a smart way. The problem with layers is that I have idea what it is in programming, unless we're talking FLASH ;)
Do you mean I make an external application which intercept the messages? When I send a udp message it's gone as far as I know. Can I intercept it?
Or do you mean I should do it in the app; put all to-be-sent messages in a Latency List? Because that would probably work now when I think about it. Was that how you did it?
I used DummyNet when bringing up a new custom UDP protocol. All that is needed is an older PC with two identical network cards and a floppy drive. In this way you can test your system over the wire, simulating packetloss, variable latency, ordering issues, etc. This method was also useful in allowing a third party test group to control network behavior and provide confidence that the protocol was solid. Once the protocol passed all the tests (and TCR's), I added support for simulating networking conditions from within the application.
Before the new protocol was tested in-game, a test application was created to allow permutation and stress testing on a single PC. This toolset proved useful in tracking down a very hard to find bug (turned out to be the classic "one-line fix" code change).
Here are my user notes for "Packet Smasher 9000" using DummyNet, an older PC and two NICs (I recommend Intel NICs; other NICs may also work OK):
I also used an in-game real-time graphical trend analyzer to verify network behavior.
Before the new protocol was tested in-game, a test application was created to allow permutation and stress testing on a single PC. This toolset proved useful in tracking down a very hard to find bug (turned out to be the classic "one-line fix" code change).
Here are my user notes for "Packet Smasher 9000" using DummyNet, an older PC and two NICs (I recommend Intel NICs; other NICs may also work OK):
Quote:
Packet Smasher 9000 Documentation
1. Boot the PS9000 Floppy.
2. Press ENTER to boot immediately.
3. Press ENTER to skip hostname and IP
4. At login: type: root <hit ENTER>
5. At Password: type: setup <hit ENTER>
6. Type these commands:
sysctl -w net.link.ether.bridge=1
sysctl -w net.link.ether.bridge_ipfw=1
ipfw add pipe 1 ip from any to any
7. PS9000 is now operational (as a Bridge). Now type:
ipfw pipe 1 config bw 64Kbit/s delay 75
or (for example)
ipfw pipe 1 config bw 32Kbit/s delay 300 plr .1
plr stands for Packet Loss Rate (0. = none, .5 = half, 1.0 = 100% loss). Using delay (in ms) and bandwidth is sufficient for our tests.
I also used an in-game real-time graphical trend analyzer to verify network behavior.
Author
@John well I'm doing a netowrk library, but I think your method would be overkill for me (in time and effort) because I don't have any computer with two network cards. And may I ask what you changed in your udp-protocol?
Quote:Original post by Wave
@John well I'm doing a netowrk library, but I think your method would be overkill for me (in time and effort) because I don't have any computer with two network cards. And may I ask what you changed in your udp-protocol?
If your are not creating a commercial product (perhaps a school/hobby project?), you might want to consider using TCP. Creating a custom UDP protocol from scratch, especially one that can scale well (on the same level as TCP), can be challenging. I strongly suggest that you read this entire thread, as well as the TCP links and history.
If you are creating a commercial product, you can pick up an old PC (with just a floppy drive) and 2 NIC cards for near zero cost. Using an old PC and DummyNet, I was able to break a commerical TCP implementation, as well as my own in-progress custom UDP protocol. The changes I made fixed bugs/deficiencies in the protocol that would not have become quickly apparent without extreme testing. Custom protocols that don't receive extreme testing end up breaking during final testing, and fixing such bugs at that stage is not optimal (causing a product to miss its ship date, etc.).
Author
Note that I'm not desinging my own IP protocol, I'm doing a Library which will rival RakNet. Raknet will always be more advanced but I'll give easy and fast impentation of multiplayer (Normal connection Lag free) for actions games like Q3 over the internet. Also I'll implend a free "I'm here" server but that's a minor last feature.
First I'll aim for UDP because it's more simple and it's faster. When I get that up and going I can think about realiable packets and ordered packets. My current Idea (which I haven't tested) is to use TCP also, for filetransfers,turnbased and strategy. Using TCP is not an option for a high peace action game, as stated in the previous thread I'll go on the bruteforce-quake3-model or something similar atleast.
I do not design for MMOG scalability, to do that is out of my scope( Am I right? ). There is no way I could run tests with even close to 100 connected reallife computers. I could think about a solution to the scale-testing problem and that would be to have a couple of computers, 1 which is host. The others all joins this host with several (50 perhaps?) games running on each machine, but I'm unsure how good this would mimic real life massive multiplayer.
My main point is that I want to make everything finnished before I ask people to help me test the library over the internet both in small and big scales. I need the best way to TEST. I think I've got the right methods now for Latency, Bandwith and PacketDrops.
First I'll aim for UDP because it's more simple and it's faster. When I get that up and going I can think about realiable packets and ordered packets. My current Idea (which I haven't tested) is to use TCP also, for filetransfers,turnbased and strategy. Using TCP is not an option for a high peace action game, as stated in the previous thread I'll go on the bruteforce-quake3-model or something similar atleast.
I do not design for MMOG scalability, to do that is out of my scope( Am I right? ). There is no way I could run tests with even close to 100 connected reallife computers. I could think about a solution to the scale-testing problem and that would be to have a couple of computers, 1 which is host. The others all joins this host with several (50 perhaps?) games running on each machine, but I'm unsure how good this would mimic real life massive multiplayer.
My main point is that I want to make everything finnished before I ask people to help me test the library over the internet both in small and big scales. I need the best way to TEST. I think I've got the right methods now for Latency, Bandwith and PacketDrops.
If you plan on using not using your code for commercial use you could use an academic emulator. Right now I think ns2 still lacks good emulation support. A good alternative is use is nctuns..or the network simulator from nctu(a uni in taiwan). You need a spare computer and fedora core 3 though. I think using the internet is not a good choice though. It is to unpredictable to give good data and the time and effort won't be worth it. Your data will be too dependent on the
paths to the few people you are able to help you out. And its not good for trouble shooting your code..ie is it the code or the network causing weird problems.
I have not used dummynet, but heard it is adequate. It gets the job done well, but lacks more complex features.
Ns2 would be nice because you could run it on cygwin on your windows box if you lack another machine. It might require to much time to learn though.
I really like nctuns because it has a easy gui to design networks. You can
set delay and delay jitter distributions, or make your own network. It will even generate an internet(simulated) which you can use to simulate the internet.
I would stay away from using TCP if any of your traffic is real time.
paths to the few people you are able to help you out. And its not good for trouble shooting your code..ie is it the code or the network causing weird problems.
I have not used dummynet, but heard it is adequate. It gets the job done well, but lacks more complex features.
Ns2 would be nice because you could run it on cygwin on your windows box if you lack another machine. It might require to much time to learn though.
I really like nctuns because it has a easy gui to design networks. You can
set delay and delay jitter distributions, or make your own network. It will even generate an internet(simulated) which you can use to simulate the internet.
I would stay away from using TCP if any of your traffic is real time.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
