• Advertisement
Sign in to follow this  

What do you do with delayed packet?

This topic is 3315 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey all. I am trying to program my own UDP client-server for my game. I was wondering what do you do with delayed packets, for example the play sends you forward input and then stop input but you receive it as stop, forward. Do you still get messages but "sort them" by order before sending them to the game-processing thread? Or is there another trick. Thanks! :)

Share this post


Link to post
Share on other sites
Advertisement
Yes, ideally.
I would think something like a unique ID on each message would help.
Even just a small incrementing counter, with an encoded ID for each member of the group.
That way you can tell the order of messages from each source.

Just my thoughts.

Share this post


Link to post
Share on other sites

Yes a sequencer number in the packets (and a way to reset it unless you use 32 bit...) If any packets come in out of order then they could be discarded to simplify the endcase.


It depends on what mechanism you are using, and it sounds like you are sending inputs to the server and whatever comes back is displayed (hopefully fairly quickly). Using that the server is the 'authority' and the player will compensate when it doesnt move for the lost input. Packet update being small increments will make it less noticable, but if it is big increments it may screw up the player feedback if it happens frequently.

Share this post


Link to post
Share on other sites
So if I get receive packet 33 before 32 I should just discard 32?

wouldn't it be wiser to "wait" until 32 arrives and sort them correctly in the array before letting the server take the packet from the server?

Note that I say "wait" because I keep receiving packets and sorting them, just deny pulling them off the list if the sequence of the packet to be pulled is not correct.

How does an FPS does that?

Share this post


Link to post
Share on other sites
This packet reordering never really happens in gameplay, though, you should still handle it. You'll occasionally get full dropped packets (roughly, 1 in 1000 or so with normal internet traffic).

What this means is you should put a 1 byte wrapping sequence number in and then drop any packets that could theoretically have come from the past.

You'll barely ever even see jitter on your packets, with non-saturated links. Course, some links have a spikey behaviour which can be annoying.

Otoh, sometimes packets will not get through at all. Then you have to put in some timeout behaviour.

Your protocol must allow for dropped packets. Theyre fairly rare, but they do happen. This implies the type of data that needs to be sent around. It should not be event based, as you showed it would die on dropped packets.

For movement on an FPS, typically you're sending things like 'Moving X degrees at speed Y'. So if you drop a single packet, you just interpolate the last couple of packets, then when you get the new one, you use it to interpolate the new position. You wont miss a stop, cause its not event based.

Share this post


Link to post
Share on other sites
Commands are always timestamped (even unreliable commands). This means that, if you get a "late" command, the system will know that the "move" command was issued before the "stop" command.

In general, because a system must deal with dropped packets anyway, it's often best to just drop packets that arrive out of order. One exception might be for reliable or status data found in the packet; that data can still be valuable. In general, you typically have multiple "streams" of messages within the packets, and for each message within the packet, you have to treat it differently, depending on the guarantees of that message (entirely unguaranteed, guaranteed unique but possibly dropped, guaranteed unique and ordered but possibly dropped, guaranteed unique and delivered but possibly unordered, and guaranteed ordered, unique, delivered).

In general, I find that the two modes that are used 99% of the time are unique/ordered (but may be dropped), and unique/ordered/delivered. It's not clear that you gain a whole lot by trying to implement other mechanisms, too.

Share this post


Link to post
Share on other sites
Unless you need to have extremely low bandwidth, I would recommend using a protocol that sends movement packets that contain complete movement state information, position, orientation, speed.

Your 2 major bandwidth hogs will be player movement packets and weapon packets. Every bit is sacred.

Send roughly 6-8 packets per second for a fast moving typical FPS. If its slower paced like Ghost Recon, you can probably get away with 6 or 4 packets per second. For my title, I sent 7.5 packets / second, 1 every 4 frames @ 30 fps.

You still will be using dead reckoning between packets and if you miss any packets.


//Example minimal movement packet. For you first movement packet I would just use floats with the real positions.
MovePacket {
short x;
short y;
short z;

unsigned char sequenceNumber;

unsigned char movingDir;
unsigned char speed;

unsigned char flags;
}

The x,y,z positions are quantized 16bit positions in the bounding box of the current level. You can probably strip some bits off Z as typically levels are larger in the X and Y dimensions.

The movingDir is a quantized angle in the X, Y plane.

Speed is quantized from 0 to MaxPlayerSpeed.

Flags is various flags that are useful to have every frame. Death being on of them.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement