Path: utzoo!attcan!uunet!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: sockets vs. streams
Message-ID: <24135:Sep505:55:0790@kramden.acf.nyu.edu>
Date: 5 Sep 90 05:55:07 GMT
References: <13526@mentor.cc.purdue.edu> <9009012315.AA08202@world.std.com>
Organization: IR
Lines: 24

Several people say that it's best to put everything into the filesystem.
But opening a file may not make sense for client-server applications.
Files may not be a very good abstraction for network communications in
general.

UNIX has from its conception given us an infinitely better solution:
passing references to files through descriptors instead of names.

So why don't we take advantage of this? Why don't we separate out
*opening* a file or *connecting* to a TCP server or *waiting* for a
connection into specialized programs? Why don't we have those programs
pass the suitably initialized descriptors to our processes? In other
words, why don't we take the modularity that we can get?

Answer: We can. Opening a file is done by your shell: $ <prog file.
Connecting to a server is done by authtcp: $ authtcp nyu smtp prog.
Serving connections is done by attachport: $ attachport -psmtp prog &.

Now, I admit that authtcp and attachport don't have perfect interfaces;
I'm developing a somewhat more general, much more portable client-server
framework. But they do the job. They take advantage of the modularity
that UNIX allows. And they'll be ported to the UNIX of the future.

---Dan