Server Help

[Pests]

Whats the best way to read packets in C/C++? I was doing it catids way but then I saw a post by ekted that said it was wrong. What would be the correct way?

[Mr Ekted]

Are you talking about handling incoming packets in code? If so, then you should define a packed structure, and pick out the fields (members) from it...

Code: Show/Hide pragma pack(1) struct SomePacket    {    unsigned char type;    unsigned short pid;    unsigned long time;    // blah blah    }; #pragma pack() // some packet handling function void func (unsigned char *buffer, int len) { SomePacket *pkt = (SomePacket *)buffer; // test acceptible length(s) if (len ==    // or "len >=" for variable size packets // pick out what you want pkt->type; pkt->pid; pkt->time; // ... }

When I use the term packet here, I really mean message, but in UDP it's one in the same.
_________________
4,691 irradiated haggis!

[Pests]

Thank you very much. I figured this would be the best way to do it. Can someone explain to me the #pragma pack() however?

[50% Packetloss]

http://webdocs.caspur.it/ibm/web/cset++-3.6.6/language/ref/rnpgpack.htm

[CypherJF]

Wow I'm confused well only by slightly lol..
_________________
Performance is often the art of cheating carefully. - James Gosling

[Bak]

variables get aligned by default in memory so if you have a 2 byte variable and then a 4 byte variable they end up taking 8 bytes because you get 2 bytes for first variable then 2 bytes filler to preserve alignment for next variable which is 4 bytes. What pragma pack does is you can specify the alginment so pragma pack 1 means alaign it to 1 byte... dont waste any bytes...

at least that's the way I interprete it... correct me if i'm wrong.

[Smong]

In order to do:
SomePacket *pkt = (SomePacket *)buffer;

Wouldn't you have to typedef struct SomePacket?

[50% Packetloss]

nope

[Cyan~Fire]

Not in C++
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[Mr Ekted]

You are correct Bak, except that it's the compiler that makes the alignment choices and sets the default. When optimizing for speed, it is preferred to keep all data members of 32 bits or less inside 32-bit boundaries, otherwise you cause extra memory accesses at the micro-code level.

BYTE DWORD would usually be implemented BYTE space space space DWORD so that DWORD starts on a new 32-bit boundary. If you use pack(1), you get BYTE DWORD with no space. What is the difference in the compiled code? Not much.

Code: Show/Hide i = pkt.byte; j = pkt.dword;

With packing off, it would look something like:

Code: Show/Hide mov eax, BYTE PTR [00440000] mov ebx, DWORD PTR [00440004]

With packing on, it would look something like:

Code: Show/Hide mov eax, BYTE PTR [00440000] mov ebx, DWORD PTR [00440001]

That access to address 0x00440001 requires a read of 2 rows of memory (00440000, and 00440004) to get the bytes necessary to make up the resulting 32-bit value.

[Cyan~Fire]

Woah I never actually understood why structs were packed 4-bytes.

So If you have a struct completely composed of bytes, it's perfectly speedy to pack it 1?

[Mr Ekted]

That will happen by default. A structure with 4 byte members will be 4 bytes in size. But in general you shouldn't go out of your way to pack stuff unless you do it to match some structure or format (eg network packet, or file format).