Archived

This topic is now archived and is closed to further replies.

serializing ints and network byte order

This topic is 5804 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I want to serialize ints and send them over a network. I''m assuming ints are 4 bytes. I did a test where I converted the ints using htonl. Then put them in a c string using memcopy. Then send them over the network and converted them back using memcopy and ntohl. Is this the right way to go about it? It worked locally but I don''t have computer that uses another architecture to test it on.

Share on other sites
Something like :

  long l = 24309532;long tmp = htonl( l );send( sock, (char*)&tmp, sizeof(tmp) );recv( sock, (char*)&tmp, sizeof(tmp) );l = ntohl( tmp );

Note: I didn''t check the actual syntax for the functions, but you should get the idea. Idem for socket error checking

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

Share on other sites
Two things to remember. htonl and ntohl accept and return unsigned longs, which means you may need to be careful if/when operating on negative numbers...(never tried it myself, but...)
You can just use localhost (127.0.0.1) to test your send/receive data if you don''t have a network to test it on.
And yes, on 32-bit systems a long is 32-bits = 4 bytes, and in every compiler i know of an int is the same length as a long.

Share on other sites
I''ve been looking source code for a unix game called Crossfire. Its for putting ints into strings is pretty much like mine only they use shifts and bitwise ands to put the ints in network byte order instead of htonl and ntonl.

They also use uint32_t instead of ints. Which I probably should do.

Its really easy to read code too, I''m learning a lot from it.

My code is pretty much like the code quoted above only I move the bytes of several ints into a string before I send it.

Share on other sites
One thing to be sure of before converting... do you actually NEED to do the byte-swap? If you are going between Linux and windows on Intel processors, you don''t have to change byte order. Of course going to a Solaris system is a different story.

I would recommend not using the htonl() type calls. Do the swapping yourself on the proper data types. Otherwise you will eventually end up with a big goober of a data bug somewhere that is going to be very hard to find. For instance, floats. floats just suck and are not necessarily encoded the same between systems. I would avoid sending floats across platforms when possible. We''ve been bitten by this one in production and had to change how we send them.

another \$.02 into the pot.

Share on other sites
Why do you expect having him write his own version of htonl is going to be more reliable than using the one that''s already been written? You either need to convert the ordering or you don''t.

If you''re primarily targeting windows my advice is don''t bother with converting byte order since all versions of windows are little-endian and one byte order is as good as another as long as you''re consistent about it. If you''re targeting unix then you probably want to stick to standard network byte order (i.e. use htonl and friends) since unix doesn''t have a standard (local) byte order.

-Mike

Share on other sites
By all means, he should use htonl() calls. And when he has data issues he can come back and we''ll have another go at it. I speak from experience on this one. Be consistent and use your own byte swapping for all data types that require it...

Again, don''t byte-swap if you don''t need it... Linux and Windows are fine with using host byte order.

• 23
• 10
• 19
• 15
• 14