Dameon

You mentioned UDP video

Start intermediate program
Listen on port 123
Target host: my_remote_server
Target port: 456

Start server
Listen on port: 456

Start client:
Connect to localhost:123

Anything sent to localhost:123 will get delayed by the intermediate program. When the server replies to sender address as is common in UDP, the intermediate program will get it, delay once again, and then send it to the client. This requires just a little bit of logic for the intermediate program. You have to know where the real server is (since there is no proxy protocol like SOCKS involved here, the client doesn't tell you), you have to track what client is sending you stuff (to send replies from the server) and need to make sure that check up on both sockets (can't just block on one of them - the other might get something).

If you are comfortable with threading, this can be easy.

Threads 1 and 2 each handle a socket. They loop until they are supposed to exit, receiving a datagram and adding it to a shared queue. Store with each datagram the time in which it should be sent (current time + latency). In threads 3 and 4, loop such that you check the first item in the queue, send it if at or past the send time, and sleep for 1-2ms. (Not terribly efficient, but much easier. You could improve this for fun). 1 and 3, 2 and 4 are effectively paired, with a queue for each pair. One pair handles the client, the other handles the server.

__________________
MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270