🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Determining packet type using UDP
Author
I understand that when TCP packets are used, the programmer should use a part of the packet itself to determine the type of the data - ie some kind of packet id.
Is it ABSOLUTELY necessary to do this when using UDP, or can I just perform a switch on the sizeof(buf) - the received data. It seems to work for me, but can anyone think of a reason why this is horribly wrong. There must be some reason, cos it seems bloody awful
The one thing you can guarantee with UDP packets is that if the packet arrives, the whole thing arrives at once, error free. This is why your scheme works.
However, this doesn''t mean you should approach UDP packet processing like you''ve suggested. As with any other software problem, you should just sit down and think things through. Is it possible that 2 different packet types for your game are going to be the same length? Sure. Its probably even _likely_ this will happen. A standard technique is to simply have a small header at the beginning of a packet
char packet_type;
short packet_size;
While packet_size may not be relevant, its sometimes useful. Approach your solution to this problem like you would approach processing arrays of input data, since in the end, that''s what the problem amounts to.
However, this doesn''t mean you should approach UDP packet processing like you''ve suggested. As with any other software problem, you should just sit down and think things through. Is it possible that 2 different packet types for your game are going to be the same length? Sure. Its probably even _likely_ this will happen. A standard technique is to simply have a small header at the beginning of a packet
char packet_type;
short packet_size;
While packet_size may not be relevant, its sometimes useful. Approach your solution to this problem like you would approach processing arrays of input data, since in the end, that''s what the problem amounts to.
2daveb: add time member
char packet_type;
short packet_size;
dword packet_time;
packet may arrive in wrong sequence.
you must ignore packets that come in wrong order
if(Game->LastPacketTime > Packet->Time)
Ignore
else
{
Game->LastPacketTime = Packet->Time
HANDLE(Packet);
}
char packet_type;
short packet_size;
dword packet_time;
packet may arrive in wrong sequence.
you must ignore packets that come in wrong order
if(Game->LastPacketTime > Packet->Time)
Ignore
else
{
Game->LastPacketTime = Packet->Time
HANDLE(Packet);
}
Author
I am fully aware of the usefulness of having a packet header to determine the packet type, but it just seems that if I know exactly what data is and should be received and its size, then using the size is an ''acceptable'' method.
The program is for a project at University and Im just wondering whether I''ll get reduced marks for not ensuring that the packet is correct in some way. By doing the following ...
If the size of the packets are the same, then the compiler will throw an error, thus preventing the problem.
As the project is an investigation into reducing network overhead, perhaps I might get away with it eh?
(Oh, yeah, and the timestamp thing is implemented too - Its possible to strip the first 16 bits of the DWORD and append at the other end so long as you have a check to cover the fact that the timestamp will wrap every 2^16 ms (65.5 secs))
The program is for a project at University and Im just wondering whether I''ll get reduced marks for not ensuring that the packet is correct in some way. By doing the following ...
bytesReceived = recv(s, ....)
switch(bytesReceived)
{
case sizeof(tConnect): break;
case sizeof(tGameUpdate): break;
};
If the size of the packets are the same, then the compiler will throw an error, thus preventing the problem.
As the project is an investigation into reducing network overhead, perhaps I might get away with it eh?
(Oh, yeah, and the timestamp thing is implemented too - Its possible to strip the first 16 bits of the DWORD and append at the other end so long as you have a check to cover the fact that the timestamp will wrap every 2^16 ms (65.5 secs))
--------------
2daveb: add time member
char packet_type;
short packet_size;
dword packet_time;
packet may arrive in wrong sequence.
you must ignore packets that come in wrong order
--------------
Eh, I'd have to argue here. There are plenty of cases where there's no need to ignore out-of-order packets. In a 3d-type game, a simple 1 byte sequence # is sufficient (and probably necessary) but its overkill to add this to all packets. Of course, this is very much dependant on your network code itself, but in general, a flexible networking scheme should be able to handle out of order arrivals for most cases.
When dealing with UDP, you want to send the largest (conglomerate) packets you can, with each datagram containing multiple "game" packets. Bloating each game packet with an extra 4 byte sequence number (and even the packet_size field is mostly extraneous, as I mentioned before) is not necessary.
In my experience, UDP packets hardly ever arrive out of order, even in flooding situations. You're _way_ more likely to have them get dropped then have them arrive out of order.
Edited by - daveb on September 24, 2000 3:55:10 PM
2daveb: add time member
char packet_type;
short packet_size;
dword packet_time;
packet may arrive in wrong sequence.
you must ignore packets that come in wrong order
--------------
Eh, I'd have to argue here. There are plenty of cases where there's no need to ignore out-of-order packets. In a 3d-type game, a simple 1 byte sequence # is sufficient (and probably necessary) but its overkill to add this to all packets. Of course, this is very much dependant on your network code itself, but in general, a flexible networking scheme should be able to handle out of order arrivals for most cases.
When dealing with UDP, you want to send the largest (conglomerate) packets you can, with each datagram containing multiple "game" packets. Bloating each game packet with an extra 4 byte sequence number (and even the packet_size field is mostly extraneous, as I mentioned before) is not necessary.
In my experience, UDP packets hardly ever arrive out of order, even in flooding situations. You're _way_ more likely to have them get dropped then have them arrive out of order.
Edited by - daveb on September 24, 2000 3:55:10 PM
Dr_Evil:
as to whether or not you can get away with it, that depends on the teacher. Since this is a reducing overhead type project, I doubt that the whole time issue will matter.
To the original problem I sugguest doing some sort of checksum byte (or two for more security) to: 1)make sure they''re your application''s packets and 2)find out the packet type, safely, based on the checksum answer.
as to whether or not you can get away with it, that depends on the teacher. Since this is a reducing overhead type project, I doubt that the whole time issue will matter.
To the original problem I sugguest doing some sort of checksum byte (or two for more security) to: 1)make sure they''re your application''s packets and 2)find out the packet type, safely, based on the checksum answer.
better safe than sorry.
if you only check size now:
#1- The code will be less readable and make a little less sense. If I saw someone''s parsing code and they were switching on the message length, I have to admit that I''d scratch my head for a second.
#2- If you have to add features in the future, you''ll have to go back and re-visit all of the messages you have to make sure you don''t overlap on length.
#3- Assuming you''re sending at least a few strings back and forth, you''ll get a bigger optimization from being able to send variable length strings, which you can''t do with your method. Not that you can''t send strings, but you''ll have to pad them to the maximum acceptable length. I suppose that if you are sending VERY FEW strings and none of them are free-form, then you might get better performance with your method, but I don''t think it''s enough of a reason given #1 and #2.
#4- If anyone tries to hax0r your server, this code has a few more areas where it might fail.
if you only check size now:
#1- The code will be less readable and make a little less sense. If I saw someone''s parsing code and they were switching on the message length, I have to admit that I''d scratch my head for a second.
#2- If you have to add features in the future, you''ll have to go back and re-visit all of the messages you have to make sure you don''t overlap on length.
#3- Assuming you''re sending at least a few strings back and forth, you''ll get a bigger optimization from being able to send variable length strings, which you can''t do with your method. Not that you can''t send strings, but you''ll have to pad them to the maximum acceptable length. I suppose that if you are sending VERY FEW strings and none of them are free-form, then you might get better performance with your method, but I don''t think it''s enough of a reason given #1 and #2.
#4- If anyone tries to hax0r your server, this code has a few more areas where it might fail.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
