Very Computer

Strange thing happens. There is a TCP socket established between A and B. Some
information flows OK between the two. However, one particular sequence of
communication does not. A writes a command to B, and immediately goes into
read() for a responce. B does something with the message and writes back to A a
struct, with some fields set to important values. When A reads it (as the same
struct - both use the same header file), however, it contains garbage. All the
fiels are set to 0 (zero). And it reads the correct size of the struct:

  n = read( sock, &preamble, sizeof(preamble) );
  if( n < 0 || n > sizeof(preamble) )
   error...

What/where can the problem be? Does A (or maybe B) have to flush the socket
after it wrote a command, to make sure it does not read its own packet back?

Thanks.
--
Simon   B-)>

: Strange thing happens. There is a TCP socket established between A and B. Some
: information flows OK between the two. However, one particular sequence of
: communication does not. A writes a command to B, and immediately goes into
: read() for a responce. B does something with the message and writes back to A a
: struct, with some fields set to important values. When A reads it (as the same
: struct - both use the same header file), however, it contains garbage. All the
: fiels are set to 0 (zero). And it reads the correct size of the struct:

:   n = read( sock, &preamble, sizeof(preamble) );
:   if( n < 0 || n > sizeof(preamble) )
:    error...

What about (n < sizeof(preamble)), or (n = 0)?

In the first case, all the information is not yet written, in the second, the
other side of the connection has gone away....

Before going any further, are processes A and B on the same physical machine?

Also sizeof may not work, as the structure may be getting padded for alignment;
I had a case where I needed to change my structure declarations (longs first,
then shorts, then chars...there's "packed struct", but my compiler wasn't happy
with that.

Ed Atlee

Also, both processes do run on the same physical machine.

--
Simon   B-)>

: > What about (n < sizeof(preamble)), or (n = 0)?

: Sorry, forgot to mention. Yes for both. And the de* tells me that the correct
: size was read (n is 18 bytes, which is what I wrote).
:  
: Also, both processes do run on the same physical machine.

: Simon   B-)>

Almost sounds like some kind of pointer problem then, but you said that
other exchanges work okay, so I don't know...let you know if anything comes to
mind, though...

Ed

    Floats, doubles, and especially *structures* are difficult to pass along
    using sockets.  Personally, I usually just write-to-ascii and transfer
    that.  There is *no* problem with passing such things between processes
    on the same machine or between the same type of machine.

    Different machines, however, may represent floating point in different
    ways (sometimes the same machine can have different ways to represent
    floats, for example, an SGI's C/C++ compilers' floats are not the same
    as those that get loaded into its homogeneous transform hardware).

    Many machines these days do use IEEE's standard for floating point, and
    so floats between those machines *may* transfer -- test and see.

    Even integers have problems: big-endian, little endian (ie. which byte
    is high, which low).

    Structures are a worse problem.  Not only may they include multibyte
    integers, floats, and doubles, with all the problems mentioned above,
    different compilers may do different things to satisfy memory
    constraints (such as, floats must begin on addresses evenly divisible
    by 8, etc).  They insert "padding" bytes (unused null bytes) in various
    places, and not even all compilers for the same platform may do this
    the same way.

    Your machine may support "XDR: External Data Representation standard"
    (1014 Sun Microsystems, Inc., 1987 June; 20p Format: TXT=39316 bytes)
    If so, check out "man xdr_simple" for such functions as xdr_bool,
    xdr_double, xdr_float, etc.  You may use these functions to describe
    simple data structures in a machine-independent fashion.

    The Simple Sockets Library (see
    http://www.auroraonline.com/sock-faq/ssl.tar.gz)
        supplies Sprintf() which I find rather useful to handle transferring
    data.  Its not perfect; ideally there'd be a way to transfer floats etc
    portably.  At least tcp/ip comes with a "net-standard" way to transfer
    integers.

    Good Luck!

--
        Charles E Campbell, Jr, PhD            _   __   __      
        Goddard Space Flight Center           / /_/\_\_/ /      

Inquire for more info.

-- Aaron

Quote:

>Strange thing happens. There is a TCP socket established between A and B. Some
>information flows OK between the two. However, one particular sequence of
>communication does not. A writes a command to B, and immediately goes into
>read() for a responce. B does something with the message and writes back to A a
>struct, with some fields set to important values. When A reads it (as the same
>struct - both use the same header file), however, it contains garbage. All the
>fiels are set to 0 (zero). And it reads the correct size of the struct:

>  n = read( sock, &preamble, sizeof(preamble) );
>  if( n < 0 || n > sizeof(preamble) )
>   error...

>What/where can the problem be? Does A (or maybe B) have to flush the socket
>after it wrote a command, to make sure it does not read its own packet back?

Mike Shannon
Houston, Texas

<!>  Once we had computers and dumb terminals.
<!>  Now we have computers and stupid terminals.
<!>  Thanks, Microsoft.