Simulating Internet Lag

Why not put some code in at the receiver that puts the messages in a queue, delayed by a random amount of time?

I once wrote a few classes that simulated internet lag.

One class held a linked list of packets that simulated the packets that were currently on their way to their destination.

I also had a class that simulated a sender and a receiver, with a linked list of received packets.

The internet class would take a sent packet and insert it into its linked list, and arriving packets would be inserted into the client's receive packets.

When a packet is sent, I immediately calculate its arrival time, whether or not the packet will arrive at all, a random huge lag spike, or even being sent multiple times (rare, but possible). One other possibility that I did not account for was the packet becoming garbled.

The variables for each client are connection speed and connection reliability.

It was a nice way to code for stability without needing an actual internet connection. I was hoping to have two client screens that showed the effects of lag from one to the other, but I never got that far.

That example allows simulation of lag with a program and communicates only with itself.

I don't know of any way of simulating internet lag over a LAN or on the same machine between two separate processes unless you have a mediating forwarding program that affects the arrival time of the packets for you.

rypyr's solution would work, too.


[edited by - Waverider on August 23, 2003 1:37:42 PM]

I would recommend that if your client is asking for the updates to have it send a unique identifier such as client number and request number and then have the server send back the same number. This way both would be able to sync with each other about the item. Remember when going over a network though... always try to keep things a small as possible. A single char would be enough for the machine, and maybe a int for the request number.

You could play tricks with your apps'' use of Winsock and delay and remove packets with an LSP (Layered Service Provider), something that sits between your apps and the real Winsock. I think this is how DP8SIM.DLL, the DirectPlay simulator does it. Maybe there are commercial LSPs out there that do this already ?

Packet Filtering with iphlpapi.dll, Windows Developer''s Journal, Ton Plooy, Windows Developers Journal, October, 2000, Volume 11, Number 10.

-cb

One of the easiest ways I can think of handling this would be to keep a simple running track of all packets sent and recieved.

For instance, client sends a packet that it expects rsponse from. Tag an extra field onto this one (a char or short int or something small). Keep track of that number. On the receiver side, if you recieve a packet that the client expects direct input from then you mark the packet number (probably the time sent). This way you can just ignore many duplicate packets if you know they have already been handled.

I''m using this kind of system and it seems to be working now. I have a small lan that it''s running on and the server with a few clients have been running for a few hours now. I''m currently servicing 6.4 millionth+ packets and counting. Granted, it''s not a full blown application and other problems may arise but so far it''s working quite well.

What I am doing is comparing the IP address when I recieve and the stamp. If it''s a combination that I have already handled then I decide what to do. If its the final packet in the system then I just ignore it. If it''s something that keeps getting sent by the other side because it''s awaiting a response then obviously the first response was never received so I just send the response again. If the old responses arrive later (at least within a reasonable time period) then they just get dumped and ignored.


Also, the client and server both are aware of a state so if for instance the client recieves a very old "trade executed" and it doesn''t currently have any open trades in waiting then the packet is simply ignored.

Works fine so far.

Webby

In all cases where you want to simulate non-normal behaviour in a network i recommend (by own experience) Nistnet - http://snad.ncsl.nist.gov/itg/nistnet/
It isn''t the easiest to setup, but it gives you a very easy way to simulate stuff like package loss, out of order delivery, lag etc etc etc.. very handy

-Mårten

Thanks guys, interesting ideas. Of the bunch, I guess rypyr is the most readily codable. It was along the ideas I was thinking anyway

My packets are already stored in a queue as they are recieved, in a "to be processed" sort of scheme. I suppose I could simply throw a random timer offset value into them and not process them until the time has expired. That should give me out of order packets, repeat requests, and all the lag induced effects I am looking for.

I suppose I should use conditional compiling for implementing the lag simulator, as I don''t want any extra artificial delays in code that goes out, I only want it for internal testing

As it turns out I corrected two more of these issues today, and I''ve gotten reports that all is now working well. Yay. I''m sure the issue will pop up again, though, before all the coding is said and done.

Sleep(100);

Sleeps for 100 miliseconds... This would create quite a lag in your program.

quote:

---

Original post by Snash
Sleep(100);

Sleeps for 100 miliseconds... This would create quite a lag in your program.

---

Yeah. The idea was to simulate lag, not slow down the entire program

The way I would do this is to simlpy add a "delay" and "packet loss %" field(s) to my internal packet headers. Since I already have an intermediary step (a buffer) between calling my API's Send() and the data actually being sent, it wouldn't be very hard to iterate over this buffer and decrement each packet's "delay" field every update. If the delay reaches 0, it's time to actually send it, otherwise keep it around for the next update. Would also be easy to do a random check to see if a packet should be dropped, which could have a cascade effect on a certain number of packets after it (lag spike). Could also randomly re-arrange packets in the buffer to simulate out-of-order, although this would be something best left for the receiving end because your seemingly out-of-order packets may end up getting re-ordered by accident by a bad router

Now that I think of it, I wonder where is the best place to perform these tricks? Should it be done before sending out the packets, or after they've been received? I suppose it doesn't make all that much difference since they get manipulated either way. The only thing you don't want is to do it on both sides, or you end up with twice the simulated lag

The downside to simulating lag is that you need bigger buffer to hold the packets that you're playing around with. It also requires more CPU time to play all those tricks behind the scenes. However, it would be very worthwhile to implement such a system. I'm almost motivated to crack open my net code and doing it... but I have to work with UnrealScript now

[edited by - foofightr on August 29, 2003 7:38:17 PM]