Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!cmcl2!rna!kc
From: kc@rna.UUCP
Newsgroups: comp.dcom.lans
Subject: Streams vs. Sockets
Message-ID: <605@rna.UUCP>
Date: Thu, 19-Feb-87 10:58:20 EST
Article-I.D.: rna.605
Posted: Thu Feb 19 10:58:20 1987
Date-Received: Fri, 20-Feb-87 21:18:51 EST
Organization: Rockefeller Neurobiology
Lines: 36

About a year ago someone posted an article comparing streams and sockets
from the perspective of implementing networking protocols. I have recently
become interested in this area, and would welcome any comments on the subject.
A repost of that article would also be nice...

I've written programs that use sockets to access server processes on remote
machines. I've never used a machine that had streams, but I've read the usual
literature. 

Here are some of my observations on sockets/streams:

	Streams has added fewer new system calls than sockets.

	Streams corresponds more closely to the ISO protocol layers.

	Streams are more easily reconfigured to meet the needs of processes.

	Streams cleans up Unix character handling outside of the networkng
realm.

	Sockets have been time tested. (Research 8 users might say
the same about streams.)

	The socket system calls seem to obviously map into the network
protocol arena. Things like accept, listen, and sendto match my notion
of how one would program network communications. I just don't know if it
is similarly easy to create applications using streams.

	The driver-like nature of stream protocol modules makes it easy
to imagine writing my own streams protocol module. (Of course I
might change my mind if I looked at the code.) I have looked at the
Berkeley code for sockets, and I haven't the foggiest notion how I
would implement a new protocol on top of the sockets mechanism.

Kaare Christian
cmcl2!rna!kc