Very Computer

I'm doing a lot of client-server stuff here, using both Inet and UNIX
sockets.  For portability reasons, I'm fdopen()ing connected sockets,
and then using fread() and fwrite() to do the i/o.  I'm having a
problem where a client writes 512 bytes to the server, and, rather than
receiving that same data back (which is what should happen), it
receives it with the last byte it sent prepended.  That is, it's like
the last byte doesn't quite make it out the other end (although the
server reads it just fine), and is pushed back to the client in front
of the data being written by the server.  Everything looks like it's
working fine on the server end.  All these socket connections have a
setvbuf(FILE *,(char *) NULL,_IONBF,(size_t) 0) call immediately after
the fdopen(), so the i/o should be completely unbuffered.  The
fread/fwrite's are of the form fread(void *, 1, 512, FILE *).  I've
found a workaround by calling fseek(FILE *, 0, SEEK_CUR) after each
fread and fwrite, but this is obviously a hack masking a problem which
I don't understand.  Any suggestions as to what the problem might be
would be greatly appreciated.  I love a mystery, but this one's gone on
too long, and I'm out of suspects.
--
Jim Tomlinson                         (206)865-6578  \  "falling snow

Boeing Computer Services   ...uunet!bcstec!voodoo!jdt  \  - Anderson/Gabriel

|> I'm doing a lot of client-server stuff here, using both Inet and UNIX
|> sockets.  For portability reasons, I'm fdopen()ing connected sockets,
|> and then using fread() and fwrite() to do the i/o.  I'm having a
|> problem where a client writes 512 bytes to the server, and, rather than
|> receiving that same data back (which is what should happen), it
|> receives it with the last byte it sent prepended....

Yessirreebob, RTFM'ing (or Remembering-what-you-read in TFM) sure would
keep the egg-on-face to a minimum.  Anyway, as the man page for
fopen/freopen/fdopen states:

     When a file is opened for update (when + appears as the second (or third,
     in the case of fopen or freopen) character of type) both input and output
     may be done on the resulting stream.  However, output may not be directly
     followed by input without an intervening fseek, fsetpos, or rewind.
     Similarly, input may not be directly followed by output without an
     intervening call to one of these functions, unless the input operation
     left the file positioned at end-of-file....

That fixed it right up (BTW, those of you who thought fflush() might help will
be receiving the home version of our game as a consolation prize).
--
Jim Tomlinson                         (206)865-6578  \  "falling snow

Boeing Computer Services   ...uunet!bcstec!voodoo!jdt  \  - Anderson/Gabriel