Author Topic: Packet Endian Conversions (Read 4114 times)

tbone · « **on:** May 23, 2010, 06:31:19 am »

I've just found this library (SFML 1.6) and in particular would like to use some of the networking classes. I noticed that in the packet class all of the integer types are corrected for Endian issues using ntohl/htonl and friends but none of the floating point types are. Is this an oversight?

P.S. I really like the Packet abstraction it feels very natural and is easily extended. When I first saw it I had this feeling of WOW this is what I've been looking for!

Laurent · « **Reply #1 on:** May 23, 2010, 12:09:19 pm »

Hi

There are many problems with floating point numbers:
- there is a standard for representing them (IEEE 754), but the C++ standard doesn't impose to use it
- IEEE 754 imposes nothing about endianess
- the C++ standard imposes nothing about the size of floating point types

So it's nearly impossible to ensure that floating point numbers are converted to the same representation for network transmission. We can just assume that the target OSes and compilers all use IEEE 754 single/double precision for the C++ types float and double, and that the endianness is consistent.

tbone · « **Reply #2 on:** May 23, 2010, 07:21:46 pm »

I agree with you 100% that there are issues with how floating point numbers are represented on each platform. But if we agree that all we can do is hope that the translation is correct don't we still need to perform byte swapping based on the little or big endian conventions? I've had to do this with an SDF file format previously and it worked out fine.

Laurent · « **Reply #3 on:** May 23, 2010, 07:54:21 pm »

If endianess is a problem then yes, we'll have to test and perform byte swapping. So far nobody complained about it, so I just wait... :lol:

e_barroga · « **Reply #4 on:** June 23, 2010, 02:23:10 pm »

What about changing to string before sending, then back after receiving?

Laurent · « **Reply #5 on:** June 23, 2010, 02:35:41 pm »

Quote

What about changing to string before sending, then back after receiving?

This is very inefficient. A number converted to string can take 3x more bytes than its binary representation. Plus the overhead of the conversions, which is significant.