TCP Write Raw data

[jacek]

strlen() is for zero-terminated strings, not for data --- use sizeof message instead.

[^NyAw^]

Hi,

Ok, it seems to work now.
When the reciver gets the raw data, I have to cast the data to a struct pointer. Right?

The other question is:

but beware that these structures are aligned and for example size of MB_Request is more than 5 bytes.
Also make sure that integers have proper endianness

What do you mean with that the structures are aligned? And how can I maintain the proper endianess, I think that I'm sending the data as big endian.

Thanks,

[jacek]

What do you mean with that the structures are aligned?

Check what sizeof( MB_Request ) returns. It contains only 5 bytes of data, yet it's bigger because of performance reasons (i.e. it contains holes between fields). Most likely the protocol expects packed data, so you have to tell your compiler to treat those structures differently.

http://en.wikipedia.org/wiki/Data_structure_alignment

And how can I maintain the proper endianess, I think that I'm sending the data as big endian.

QSysInfo::ByteOrder will tell you whether you are using big-endian or little-endian system and you have to convert values to endianness required by the protocol.

[^NyAw^]

Hi,

Check what sizeof( MB_Request ) returns. It contains only 5 bytes of data

It returns me "14". The structs are 7 bytes(Modbus/TCP header) + 5 bytes (Modbus header) that sum 12. So I think that the struct "MB_Message" contains 1 byte for the first struct and another byte for the second struct.

Thanks,

[^NyAw^]

Hi,

Ok, thanks for the link of "Data structure alignment".

So, the "Modbus/TCP header" is 7 bytes. The "Modbus header" is 5 bytes. A total of 12 bytes that are 12*8 = 96 bits that are 32 bit aligned.
So, why "sizeof(MB_Message)" is returning me 14 bytes?

Thanks,

[jacek]

So, why "sizeof(MB_Message)" is returning me 14 bytes?

Because there are one-byte holes after unit_id and function_code fields.

I've attached a small application. It prints the addresses of all fields, so you can see how they're placed in the memory. If you use GCC, you can uncomment the #define in line 7 and comment out the one in line 6 to see how unaligned (a.k.a. packed) structures look like.

[^NyAw^]

Hi,

Ok, so every struct have to be 32-bit aligned.

Thanks,

[jacek]

Ok, so every struct have to be 32-bit aligned.

Yes, but only in memory on 32-bit (and pseudo-64bit) machines. Other machines might have different alignment. Also usually you don't align data in files* or in network communication.

* Unless the file format was designed for fast access.

[^NyAw^]

Hi,

Yes, but only in memory on 32-bit (and pseudo-64bit) machines

Of course, of course. Them are 32-bit aligned because of using 32-bit processor.

Another question. I'm compiling the program with Visual Studio 2003 .NET and when using GNU/Linux I will have to compile with GCC, will the behavior be different? I'm asking this because I don't know what "__attribute__((packed))" do.

Thanks,

[jacek]

I'm compiling the program with Visual Studio 2003 .NET and when using GNU/Linux I will have to compile with GCC, will the behavior be different? I'm asking this because I don't know what "__attribute__((packed))" do.

__attribute__((packed)) is a GCC extension, so it won't work with VS. Basicly it sets the packed attribute for given class, which tells the compiler not to align it. It's perfect when you want to sent your structure directly over the network or read/write it from/to a file, but it's also completely unportable.

VS probably has something different that will allow you to pack the structure. Since it's .NET, it might have a form of some annotation.

[^NyAw^]

Hi,

Ok, so it's only important because of the data that will be sent becomes longer and it could be smaller. So if I force to not pack, send it, and recive to another program that loads the data into the struct, the struct will contain the same data.
But if forcing not to align the data, when using the variables in memory will produce TLB miss or a page faults (from the link of "Data structure alignment").

Thank you very much,

[jacek]

Ok, so it's only important because of the data that will be sent becomes longer and it could be smaller.

It isn't about sending few bytes less, but about adhering to given protocol. If it requires you to send a one-byte field followed by two-byte one, you can't send 1B of data, 1B of garbage and then 2B of data. If you use some custom protocol and both sender and receiver follow the same rules of alignment, you don't have to worry about it, but if you want to implement Modbus, you have to follow its specification and there are no holes in Modbus messages.

But if forcing not to align the data, when using the variables in memory will produce TLB miss or a page faults

Yes, some CPUs can't even fetch unaligned data from memory, so accesses to such structures might be split into several operations.