No byte-swap in member of struct

[Frontier789]

Considering the following situation: server.cpp :

struct A
{
    int a;
};
int main()
{
    ...
    //connect, etc
    A a1;
    a1.a=42;
    int i1=42;
    sfn::Message msg1;
    msg1<<a1<<i1;
    //send msg1
    ...

client.cpp :

struct A
{
    int a;
};
int main()
{
    //connect, etc.
    sfn::Message msg1;
    A a2;
    int i2;
    //recieve msg1,
    msg1>>a2>>i2;

    std::cout<<a2.a<<std::endl;
    std::cout<<i2<<std::endl;
    ...

correct me if i misunderstood something, but wouldn't a2.a and i2 be different if the server's and the client's byte order are different?

[binary1248]

SFNUL performs the byte swap for you if you enable it in the CMake configuration. Obviously you only need to enable it if you know it will be necessary. If your application is only run on machines with the same endianness, this is a moot point. Most consumer hardware these days are little-endian anyway, so you would know when you are using big-endian hardware.

[Frontier789]

How SFNUL is able to detect the ´int´ field in a struct in order to perform a byte-swap on it?

[binary1248]

Hmm... yes, I misunderstood your original question. The int would be swapped, but the struct wouldn't. C++ doesn't provide a way to programmatically inspect class/struct members, so streaming a struct into a message would only work if the endian-ness on both machines is the same.

Like I said, this should normally not be a problem, because most hardware you are able to get a hold of these days are little endian. If you work with non-little endian hardware, you will have to stream each member for itself into the message and stream them out individually at the other end.

[Frontier789]

Every tutorial i read about networking said that one must be careful with byte order, but i checked and my computer, phone, tablet and my father's computer are all little endian structured. Thank you for pointing that out for me.

[binary1248]

The way networking literature works, they always tend to be based on older literature. If you carefully trace the reference chains back to their roots, you will notice that they all start with a handful of books/people dating back to the 1970s-1990s. Back then, little-endian systems weren't as dominant as they are nowadays, hence it was good advice to precautiously byte swap, because you could never really be sure that the server/client hardware that is going to run your software was of a specific endian-ness.

Even worse, common server hardware at that time (e.g. Sun's SPARC and IBM's POWER) endian-ness would often end up being the opposite of common client hardware (Intel x86) endian-ness, almost guaranteeing that a swap was required in a client-server set up. Since acquiring and running that kind of server hardware was much more expensive than just running "consumer" (not really, there is still specialized server hardware these days) hardware on servers, data centres started to shift from those big-endian architectures to the little-endian architectures at the turn of the millennium. You can check the TOP500 lists for the most powerful supercomputers and you will notice most of them on the current list are little-endian based. The opposite was true 20 years ago.

The problem that many people seem to misunderstand is that while the hardware evolved, nobody cared to update the accompanying literature. Many of the "good" books recommended by "experienced" (i.e. old) networkers still all stem from that era and it won't change until someone else writes new literature from scratch. Considering the time that you need to invest into writing such literature, it probably won't be done any time soon and beginners will keep believing that endian-ness is still as important as it was 30 years ago. Tutorial writers are no different.