Artificial Latency and package dropping

Wow, i am asking a lot of question recently

But this one just want your opinion

I am using UDP and since it is not reliable i have to test for lag and dropped messages

it is in the vein of

if (rand.nextDouble() > .8)
	ProcessPacket()

is 80 percent dropped packages too high

The reason i’m asking is because it works well under 50 percent but under 80 percent, sometimes the pings don’t get to server and client and they time out

Can i expect 80 percent dropped packets when i deploy my game because that would mean i will have to increase the timeout parameters

Those are huge drops. I suggest you stick with TCP. Creating a reliable way to handle dropped packets in UDP is cumbersome. It’s been done before and so isn’t something you need to re-invent however.

Read these articles if you’re sticking with UDP: http://gafferongames.com/networking-for-game-programmers/

Sorry if i wasnt being clear, so ill try to be concise this time
Is 80 percents dropped packages using Udp normal?

No, that’s way too high. Think about it, why would anyone use UDP if it dropped that many packets?

UDP is useful when packages quickly get outdated and a dropped packet here and there isn’t a problem. This is usually the case for movement in action games. If you’re sending 30-something packets per second, there’s no point in resending a single lost packet, since a more up-to-date packet hopefully arrives soon anyway. If you actually need a guarantee that all packages get delivered and arrive in order, you should definitely use TCP. There’s no point in attempting to implement your own most likely inferior version of TCP unless you know exactly what you’re doing when there’s a perfectly fine TCP implementation available. Just remember to turn off Nagle’s algorithm if you’re doing real-time games.

Also, depending on your send rate I guess but the usual packet loss for UDP is around 0% :slight_smile:
I don’t think there is a game that can compensate for 80% packetloss and still look good.

These days its typically almost no packet loss or reordering… Or you get close to no packets at all and your wasting your time. There are some exceptions with some wireless stuff. But typically this is all hidden in lower layers of the stack as well.

Did you know that upd still can fragment packets and wait for them if the MTU size is smaller than packet size?

Perhaps its too late. But really always start with TCP and only change if there is a really really good reason to. With UDP you need to know about flow control, congestion collapse, and the 2 generals problem at a minimum. Considering it took experts in the field years to get this all right in TCP, it pays to use that expertise and experience.

Well… I have a friend who happens to have the most flakey ADSL connection I’ve ever seen. We can basically turn invincible as long as he’s the one driving in Planetside 2. Aiming the turret attached to a mega-stuttering buggy is a bit hard though. xd