[WinsockUDP] Reliable packets?

Started by
24 comments, last by hplus0603 15 years, 10 months ago
Hi guys I'm creating a multiplayer FPS game using winsock & udp, and i need a way to check if packets are missing.... I' thinking about putting 4 bytes header to check packet ordering....what do you think about that? :)
Advertisement
Quote:Original post by roby65
Hi guys
I'm creating a multiplayer FPS game using winsock & udp, and i need a way to check if packets are missing....

I' thinking about putting 4 bytes header to check packet ordering....what do you think about that? :)



You must send "snapshot" of game in each packet. Of someone drop - ignore it. (missing of packet is not trouble)

Each packet contain timestamp when created, and remember timestamp of last received packet. If you have received packet "older", then ignore it. (Order checking).

Also read about Lag compensation, for "hide" network latency.

And .... read FAQ :)




Here's the problem.....

In this game, you can jump, crouch, shoot, change weapon, die, drive a car....and also you can fall, be pushed by objects etc.

So, if i do a "snapshot" of the game with more than 3/4 players then the packet could arrive at more than 1 kb.

information of a player are:

x,y,z, rotation,fx,fy,fz, health (float)
flags (crouched, running, walking, shooting, jumping (int))
weapon armed (int)

totally....40Bytes per player :|

imo it's too much.... :(
Quote:Original post by roby65
Hi guys
I'm creating a multiplayer FPS game using winsock & udp, and i need a way to check if packets are missing....

I' thinking about putting 4 bytes header to check packet ordering....what do you think about that? :)
That's an excellent idea, however I'd use 2 bytes instead of 4, and write some special code to handle the integer wraparound after 65535. This method is sometimes refered to as sequenced packet numbering, and it helps to prevent errors caused by packets arriving out of order.
Quote:Original post by TheGilb
Quote:Original post by roby65
Hi guys
I'm creating a multiplayer FPS game using winsock & udp, and i need a way to check if packets are missing....

I' thinking about putting 4 bytes header to check packet ordering....what do you think about that? :)
That's an excellent idea, however I'd use 2 bytes instead of 4, and write some special code to handle the integer wraparound after 65535. This method is sometimes refered to as sequenced packet numbering, and it helps to prevent errors caused by packets arriving out of order.


i would like to use 2 bytes too, but when a clien will receive 65535 packets then....boom, i don't know how to do because the packet count will restart to 0 and all the packets will be throwed away :P
For wrapping you can propably get away with some code like this:

uint16 nExpectedSequence = somenumber;uint16 nActualSequence = thepacket.sequence;if (nActualSequence >= nExpectedSequence) { nExpectedSequence = nActualSequence +1; ProcessNetworkMessage();} else { // a wrap. if (nActualSequence+32000 < nExpectedSequence) {  nExpectedSequence = nActualSequence +1;  ProcessNetworkMessage(); } else {  ThrowAwayNetworkMessage(); }}


As a note to packet size:
It really depends on how often you send your refresh. If you send a refresh 10 times/sec, you will send 480 bytes/sec per player. If all players can see all players at all times, this will grow pretty fast once # of players start to increase. But here you can do lots of optimizations; players that cant see each other does not need to receive updates for the other players etc.

My suggestion is to not worry about this now, but focus on getting the game runnning. Once you have it running, optimize it where needed.
www.ageofconan.com
Quote:Original post by roby65

i would like to use 2 bytes too, but when a clien will receive 65535 packets then....boom, i don't know how to do because the packet count will restart to 0 and all the packets will be throwed away :P


Yes, 4 bytes should be enough for anyone.


Wrap to zero is not a problem. If you assume strict ordering (all packets must arrive in sequence, numbers are sequential, no packets may go missing), then you simply store the packets until you receive all the missing ones, or you don't receive a missing one for n packets, in which case you close the connection.

For counter, simply remember last received packet. If next packet is n+1, then it'll work even if counter wraps around, since your 16-bit variable will as well.
Quote:Original post by roby65
Here's the problem.....

In this game, you can jump, crouch, shoot, change weapon, die, drive a car....and also you can fall, be pushed by objects etc.

So, if i do a "snapshot" of the game with more than 3/4 players then the packet could arrive at more than 1 kb.

information of a player are:

x,y,z, rotation,fx,fy,fz, health (float)
flags (crouched, running, walking, shooting, jumping (int))
weapon armed (int)

totally....40Bytes per player :|

imo it's too much.... :(


Then you can look into delta-compression, which fix that particular problem.

Then you can also look at packet segmentation if your packets are > MTU.

Everything is better with Metal.


You can create channel of data and give different priority, so group data with priority.

Each packets can contain several channels, so some data doesn't been send every time, only if urgently need to send or send when "timeout priority occur".


Quote:Original post by Ramsess

You can create channel of data and give different priority, so group data with priority.

Each packets can contain several channels, so some data doesn't been send every time, only if urgently need to send or send when "timeout priority occur".


sorry, i can't understand :(

This topic is closed to new replies.

Advertisement