Newsgroups: comp.protocols.tcp-ip
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Sockets vs streams.  An attempt to answer the original question
Message-ID: <1990Sep4.203034.2655@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <9008311500.AA12356@ftp.com>
Date: Tue, 4 Sep 90 20:30:34 GMT

In article <9008311500.AA12356@ftp.com> jbvb@ftp.com writes:
>    ...That's all most customers want.
>
>I see where our viewpoints differ: I am selling applications to end-users,
>and I intend to support them.  Most of the end-users who use our Development
>Kit for one-off or in-house applications are probably quite satisfied with
>open/read/write/close.  However, I am careful to advise any OEMs who develop
>for resale to pay close attention to the flags and error codes...

I was writing from the down-in-the-wires viewpoint, where *any* user process
is a customer.  And on the whole, I remain unrepentant. :-)  It should be
possible to use open/read/write/close, with (say) perror when something
goes wrong, without major problems, assuming that error-message-and-die
is a reasonable thing to do on failure.  A requirement for fault tolerance
does require closer attention to error handling, as in non-networked code.
Also as in non-networked code, a requirement for carefully optimized use
of system resources requires attention to flags and details.  And anyone
building production code should be aware of the grubby details, so that
he can recognize the one case in a hundred where some of them are relevant.

However, I continue to believe that what most applications want to see is
a reliable bidirectional pipe, perhaps set up in slightly odd ways but
thereafter used via read/write/close, with invisible recovery from transient
problems and a suitable errno value on hard failure.

The resemblance to a Unix file is not accidental. :-)
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry