Path: utzoo!utgpu!news-server.csri.toronto.edu!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: Are sockets the wave of the future?
Message-ID: <16026:Aug2719:29:0290@kramden.acf.nyu.edu>
Date: 27 Aug 90 19:29:02 GMT
References: <1990Aug26.065346.13988@Solbourne.COM> <8076:Aug2616:42:1890@kramden.acf.nyu.edu> <2487@east.East.Sun.COM>
Organization: IR
Lines: 46

In article <2487@east.East.Sun.COM> geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
> Quoth brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (in <8076:Aug2616:42:1890@kramden.acf.nyu.edu>):
> #auth provides that advantage without that disadvantage! Again, it was
> #designed for client-server applications, unlike RPC.
> Dear Dan,
> 	You seem to understand these things, so maybe you can help me
> with a little semantic problem. Every time I feed a .x file to rpcgen,
> it insists on spitting out client and server stubs, which I find
> convenient for building my distributed applications.  Yet you say that
> RPC wasn't designed for client-server applications.  I'm confused...

Dear Geoff,

Let me illustrate with a trivial example: TAM, Trivial Authenticated
Mail, included in authutil. It is a complete mail system, including a
short shell script for sending mail, a shorter shell script daemon to
receive mail on port 209, programs to set up, print, and empty your
TAMbox, and scripts that convert TAM to regular mail and easy-to-read
formats. It uses an extensible protocol. It is much more secure than
sendmail: since it is implemented on top of auth, *all* forgeries above
TCP are stopped. (Most, if not all, forgeries at a typical university
are done without breaking TCP. auth completely eliminates that problem.)

TAM is short enough to be bugfree, doesn't run as root, and includes the
niceties you'd expect of a friendly mail system: sending you copies of
what you send out, including the TCP address of received mail in case of
DNS trouble, not loading the header with mounds of junk, and reading
mail with no delay.

All the code necessary to set up TAM, including security checks,
/etc/services and /etc/rc.local modifications, and comments, takes 241
lines. That's 5K. In contrast, the README, protocol description, and man
pages take 12K.

Finally, TAM will be trivial to port to any communications system
supporting the same interface for reliable, sequenced, two-party stream
communication.

Try to set up an RPC-based mail system with the features listed above.
You'll quickly appreciate the fact that RPC and client-server are quite
different concepts.

---Dan
``Networking systems so powerful that you can send mail around the
world, with a minimal risk of forgery, in just 5K of code including the
mail reader. Science fiction!''     ---hypothetical Internet guru, 1988