I am pretty sure that your problem is on the C side.

Try test on how many bytes read actually read and what
is the content of the bytes.

Arne

atoi() needs a trailing zero and it hasn't got one here.

However the assumption /could/ be true in the OP's environment.  Or more likely
some related assumption, such as that a float is represented in C memory as 4
bytes in IEEE little-endian format -- in which case something like the above
code but with an additional byte-swapping step would be correct.

The key is to do one of three things.

1)    Create an interchange format which is designed to be portable and
      which is text based -- as Dale suggests.

2)    Create an interchange format which is deigned to be portable and
       which is binary based -- in which case the spec for the format must
       lay down the exact layout at the bits and bytes level.  For instance
           "the next four bytes are a 32-bit IEEE floating point
           number in little-endian format"
       Obviously your C and Java code will reflect the specification.

3)    Create an interchange format which is /not/ designed to be portable
      and which is binary based.  In that case you have no real control
       over when it stops working unless you control completely the
           - machines it runs on
           - compiler (make and version) the compiles it
           - compiler options

(3) is obviously irresponsible, but there's no general reason to prefer (1)
over (2) or vice versa.   Of course, if you /do/ choose to use (2) then there's
nothing to stop you choosing the format to be one that you can easily implement
for your current /actual/ machines.  In which case you might easily end up with
an implementation which looked like the above code on the 'C' end of the link.

To the OP:  If you are writing the data out using a java.io.DataOutputStream,
then you are implicitly defining a spec like (2).  So you should read the
javadoc for DataOutputStream to understand what it puts on the net at the
byte-level (actually it will write a float as 4 bytes in big-endian order).
Then you should write your C code to parse that.  If you are running on
ordinary Intel-like machinery then the layout of a C float in memory is
little-endian, so you could use code like the above, but you'd have to reverse
the bytes before converting them to a float.

   -- chris

Actually the Java code is not that bad.

It sends binary floats using standard IEEE floating
point format in standard network byte order.

Which is a very well defined format that almost
all non embedded computer will understand.

The problem is that the C code did not use ntohl.

That constructor variant is general considered
bad practice.

Arne

I prefer to use structured messages with a count as the first value,
something like "n,value" in this case, where 'n' is a fixed length
number, e.g. four digits zero filled on the left, that gives the length
of the "value" string + 1 for the comma.

This makes reading the message simple:

read 4 bytes (the length of the rest of the message)
convert to binary (lth)
read lth bytes into a value buffer
append a null character as the string terminator
skip the first byte (the comma) and the rest of the string is the value
that was sent.

You can transfer any combination of bytes with this method (including
binary values and UTF-16 encoded byte strings) but IMO you're better off
sending a plain ASCII string because:

- the ability to display the whole message without decoding it
  makes debugging a lot easier
- this allows the value to be retrieved with a single read (lower
  overhead than byte by byte reading)
- using formatted messages of this sort enables you to spot corrupted
  data and do something about it: in this case you could check that the
  comma is the first byte after the length.
- by sending an ASCII byte string you avoid big endian / little endian
  conflicts between hosts and other binary traps
- messages formatted this way are easy to assemble and parse in both
  Java and C

You must check that you've read the required number of bytes in case the
message got split during transmission. Remember that TCP/IP can split
messages up if buffer sizes differ along the route and that a split
message isn't necessarily recombined at the destination host.