Advertisement

Efficient Packet Structures - Help?

Started by December 27, 2001 05:08 PM
29 comments, last by kurifu 23 years ago
For packets that are going to be of variable length, couldn''t you put the length as the first value in the packet, peek recv that into a small buffer, and then create a buffer of the appropriate size to actually recv it to?

-----------------
The Goblin (madgob@aol.com)
-----------------
"Before critisizing somebody, walk a mile in their shoes. That way, when you do critisize them, not only will you be a mile away, but you''ll also have their shoes!"
- The Goblin (madgob@aol.com)
nope thats a bad idea
when u recieve a packet and u specify a buffer and its lenght winsock takes that value either as the size of the buffer or how much it should recieve
the thing is to make a big enough arraysay char buf[2048] unless ull send more
and that way ull never have the problem of getting something too big

but on another note or question actually
say im making quake 4 or UT2
how did them ppl handle sending things like rockets
did they first create a predertermined array and then fill it with the data and then send all of it or part of it?
or make a linked list and then send the data there?
if it was completly dynamic and u had like 16 - 32 players to worry about wouldnt it be kind of slow having to create a new buffer on the free store just to send a packet?
this is a more overall desing question

ppl seem to be always talking bout sending this snapshot every so and so milliseconds but since different data will be sent to each player the packets would vary in size so that would mean like 32 allocations and deallocations every 20 - 50 milliseconds
and tahts just for sending
am i missing something here?
Advertisement
You are going to send a simple array of data that tells the server that you would like to launch a rocket... very simple, t echnically this only requires one byte of data.

Since the server should be keeping track of your mouvement in mych the same pattern, if you can actually launch a rocket (ie the server tests to see that you have a rocket launcher, and enough munition ), then it returns data to all the computers representing the speed, direction, and origin of the rocketr... the clients than draw it.

The server will also keep track of the collision detection to tell you when someone has been hit, not the client... as this avoids cheating.

Gamedev''s AI Auto-Reply bot.
Gamedev's AI Auto-Reply bot.
Yes, the packets will be of a varying size, but there will be a structure andf MAX size to it, and hence casting data structures is an easy, effective, and perfectly acceptable manner to complete.

In response to whomever posted to send the size in the packet, that can be done, but should I make reference to the SSHv1 packet hacks that have been going around? I feel that it would impair the security of the packets to do so, especially when there is another way around it.

CRC checks will be shortly implemented into the packets.. I just have to write a few functions, I will also be providing a basic dual key encryption on the packets to in the near future to increase their security.

Gamedev''s AI Auto-Reply bot.
Gamedev's AI Auto-Reply bot.
People like to get way too complicated with this. Here''s my basic format:

  //MESSAGE TYPES#define MSG_SAY    0x01//MESSAGE LENGTH CONSTANTS#define MAX_SAY    256typedef struct NETMSG{    BYTE bFlags;//PACKET FLAGS (GUARANTEED,ACK)    USHORT nId;//PACKET ID    USHORT nType;//PACKET TYPE ID    USHORT nLength;//PACKET LENGTH    NETMSG(USHORT type){        nType = type;            }}*PNETMSG;typedef struct NETMSG_SAY : NETMSG{    USHORT nCharacterId;//WHO SAID IT    TCHAR szText[MAX_SAY+1];//WHAT THEY SAID    NETMSG_SAY(USHORT character, LPTSTR text) : NETMSG(MSG_SAY){        _tcsncpy(szText, text, MAX_SAY);        nLength = sizeof(NETMSG) + sizeof(USHORT) + ((_tcslen(szText) + 1) * sizeof(TCHAR));    }}*PNETMSG_SAY  


Then when you send the packet, use the nLength member to determine how many bytes of your packet to actually send. On the receiving side, take your received packet, cast it to a (PNETMSG) and use this structure to test the nType member. When you figure out what type of packet it is, cast it to the correct message type and handle accordingly.
Only one problem I see with that is that because you have the length stored at the very end, you will have to receive all of your data string, even if only 1 byte of it is used.

This is what I am trying to avoid.

Gamedev''s AI Auto-Reply bot.
Gamedev's AI Auto-Reply bot.
Advertisement
Could someone also explain to me how you get those nice looking code blocks like above?

Gamedev''s AI Auto-Reply bot.
Gamedev's AI Auto-Reply bot.
Type:

[_code_] and [_/code_]

or

[_source_] and [_/source_]

but take out the underscores (_)

BTW Normally you receive all your data before using it, especially considering that UDP is message based.

Regards,


Dire Wolf
www.digitalfiends.com

Edited by - Dire.Wolf on December 31, 2001 12:17:33 AM
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
Actually, the nLength member appears at the front of the packet. When you derive a class / structure , the members of the children are added to the end of the memory area of the parent.

With the packet structure I have above, if you place any variable length fields at the end of the packet structure, you can reduce the number of bytes transmitted. You still allocate a structure which will allocate all of the bytes on the sending side, but you only have to send enough bytes to send the valid data.
Ah... I see it now

Essentially the same idea that I was going for. I did finally complete my code and tested it. It works without fail... though I have to now start taking into consideration problems such as splitting the packets, and so forth.

None the less though what I have for now does work over my LAN, and in the near future I am going to write the packet disassembly and reassembly code. Is there any chance that the data itself will be split up somewhere along route?


Gamedev''s AI Auto-Reply bot.
Gamedev's AI Auto-Reply bot.

This topic is closed to new replies.

Advertisement