Socket problem, please help

D. Jason Penney penneyj at servio.UUCP
Thu Apr 12 06:58:37 AEST 1990


In article <2812 at milton.acs.washington.edu> eliot at dodongo.engr.washington.edu (Eliot Lim) writes:
>Can anyone tell me why the following piece of code fails?  I've been
>banging my head on the wall for days and I've had 2 other people look
>at the code for obvious bugs.  I will only list pseudo code as I'd
>like to know if there's anything fundamentally wrong with my approach.
>
>The program is a file server/client using sockets for transfer.
>The client program prompts the user for a filename, sends it through
>the socket to the server, the server reads the file and sends it back
>through the socket.
>
[snip]

Acch! Phht!  I hope this gets added to the regularly asked questions file.

BSD stream sockets are STREAMS.  This means that they don't honor any
kind of record boundaries.  (BTW, the fflush(socket) is rather alarming; if
you're using read(2) and write(2), this means socket is an fd, whereas
fflush is expecting a FILE* for an argument.  If you're using fdopen()
to associate a FILE* with the socket, other peculiar things can happen.)

This means that the program as written will produce unpredictable results
unless you add some syntax so that the server can distinguish the file name
from input.  Further, the number of bytes sent in any single call on the
server side doesn't necessarily have any correlation to the number of bytes
received on the client side.

Why the program exits prematurely can't be answered by examining the
pseudo-code.  You MUST have some kind of exit routine, such as fault handler,
or some other exit condition.

It's possible that I've missed the boat entirely, because the pseudo-code
doesn't show things like the exact syscalls used to open, read and write the 
socket.  If this is the case, please accept my apologies, and follow up with 
e-mail; perhaps I can help.

In any event, my original point holds:  the fact that BSD stream sockets
do NOT observe record boundaries is a good candidate for the commonly-asked
questions posting.

-- 
D. Jason Penney           Ph: (503) 629-8383
Beaverton, OR 97006       uucp: ...uunet!servio!penneyj (penneyj at slc.com)
"Talking about music is like dancing about architecture." -- Steve Martin



More information about the Comp.unix.wizards mailing list