18 users logged in
Proud partner of GDC 2025
Before posting, review our community guidelines.
Support GameDev.net with a monthly GDNet+ subscription!
UDP and "Need to get there" Messages
February 15, 2003 05:29 AM
Hi Everybody,
Since UDP is faster and "less Bandwith consuming" than TCP, I thought it might be the better Idea for games. But I have a little problem with the fact, that I can not be sure that the other side will get my Messages. With "Update State" Messages, it''s not a problem. The client does not have to get every single one of them. But what is about Command Messages? For example, when a client sends a Message, saying that he is shooting? It the Server does not get this Message, I am in big trouble, am I not?
How can solve this Problem?
thx!
286
February 16, 2003 12:19 AM
Ok basically what you want to do is encapsulate your packets with a header. In this header you would have a sequence number among other things. Everytime you send a packet, you put the sequence number in the packet, send it and then increment this sequence number to be ready for the next packet.
When the packet arrives on the other end you check the sequence number against the last one you recieved.
IF the packet arrived in order, its sequence number should be 1 more than the last one. If this true, then you process the packet. Also increment the last recieved seqeunce number on the recieving end.
If its less than or equal to the last sequence number you got, then this packet is a late packet and is a duplicate. You can just throw it away at that point.
The other case is if the sequence number is more than the old sequence number+1. In this case the packet has arrived early and out of order and should be buffered in some sort of list of packets.
On the next loop through before you start processing data off the line again, run thru your list of packets to see if you have any packets that have a sequence number 1 greater than your last sequence number recieved. If it is, pull it off the list and process it. Then run thru the list again, and keep doing this until you find no packets that can bring the order up to date. Once you cant find another packet that meets the requirements, bail out and start reading packets off the line again.
From this point on just repeat everything again and again while the client is still "connected".
That part handles out of order packets, however it doesnt handle packets that are just totally dropped.
To handle packets that are totally dropped you need some sort of mechanism to tell the otherside hey i got this packet. Which can be done in something like the following manner:
When you send a packet and want its delivery to be guaranteed, specify this in the header, a boolean will suffice. Also add this packet to a resend buffer in case the packet gets dropped.
When the packet arrives on the other end, send back an ACK packet to the sender with the sequence number of the last in order packet that you processed. When the sender recieves this packet he checks the ACK sequence number against the buffered packets in the resend list. Any packets in this list that have a seqence number less than or equal to the ACK sequence number are removed and considered successfully delivered.
Now theres a small issue with doing this in that what happens if your ACK packet gets lost? Basically on the side that sent the ACK you want to send out an ACK packet every so often (say 500ms or so, really depends on your needs) if an ACK hasnt been sent lately. Also on the sending side, since the original packets may have been lost, the recieving end may not know to send an ack because it never recieved the packets in the first place. In this case if the sender hasnt recieved an ACK packet in a while, resend all the packets in the resend buffer. This is where the the first part of this reply comes in to play, some of these packets may end up late and out of order.
Well, I might have forgotten a thing or two, but thats about the jist of it. This is by no means the best way of doing this, just one example and maybe to point you in the right direction.
Oh one more thing, you might wanna keep separate sequence number counters for both guaranteed and non-guaranteed delivery packets. And you really only need the sequence numbers for the non-guaranteed packets just to ensure in order delivery. If you dont need them in order, I think you can get away with out them.
Long post, but I hope this helps. =)
-=[ Megahertz ]=-
When the packet arrives on the other end you check the sequence number against the last one you recieved.
IF the packet arrived in order, its sequence number should be 1 more than the last one. If this true, then you process the packet. Also increment the last recieved seqeunce number on the recieving end.
If its less than or equal to the last sequence number you got, then this packet is a late packet and is a duplicate. You can just throw it away at that point.
The other case is if the sequence number is more than the old sequence number+1. In this case the packet has arrived early and out of order and should be buffered in some sort of list of packets.
On the next loop through before you start processing data off the line again, run thru your list of packets to see if you have any packets that have a sequence number 1 greater than your last sequence number recieved. If it is, pull it off the list and process it. Then run thru the list again, and keep doing this until you find no packets that can bring the order up to date. Once you cant find another packet that meets the requirements, bail out and start reading packets off the line again.
From this point on just repeat everything again and again while the client is still "connected".
That part handles out of order packets, however it doesnt handle packets that are just totally dropped.
To handle packets that are totally dropped you need some sort of mechanism to tell the otherside hey i got this packet. Which can be done in something like the following manner:
When you send a packet and want its delivery to be guaranteed, specify this in the header, a boolean will suffice. Also add this packet to a resend buffer in case the packet gets dropped.
When the packet arrives on the other end, send back an ACK packet to the sender with the sequence number of the last in order packet that you processed. When the sender recieves this packet he checks the ACK sequence number against the buffered packets in the resend list. Any packets in this list that have a seqence number less than or equal to the ACK sequence number are removed and considered successfully delivered.
Now theres a small issue with doing this in that what happens if your ACK packet gets lost? Basically on the side that sent the ACK you want to send out an ACK packet every so often (say 500ms or so, really depends on your needs) if an ACK hasnt been sent lately. Also on the sending side, since the original packets may have been lost, the recieving end may not know to send an ack because it never recieved the packets in the first place. In this case if the sender hasnt recieved an ACK packet in a while, resend all the packets in the resend buffer. This is where the the first part of this reply comes in to play, some of these packets may end up late and out of order.
Well, I might have forgotten a thing or two, but thats about the jist of it. This is by no means the best way of doing this, just one example and maybe to point you in the right direction.
Oh one more thing, you might wanna keep separate sequence number counters for both guaranteed and non-guaranteed delivery packets. And you really only need the sequence numbers for the non-guaranteed packets just to ensure in order delivery. If you dont need them in order, I think you can get away with out them.
Long post, but I hope this helps. =)
-=[ Megahertz ]=-
-=[Megahertz]=-
1,065
February 27, 2003 08:38 AM
I don''t even consider the "make me shoot" messages to be extremely vital. For things like transferring levels to the client that he doesn''t already have, I just open a TCP socket and send the information over that.
~BenDilts( void );
~BenDilts( void );
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement