[ih] Ping Eduardo A. Suárez (was Re: What is the origin of the root account?)

[dot at dotat.at (Tony Finch)]

On 18 Apr 2013, at 03:30, Jack Haverty <jack at 3kitty.org> wrote:
> 
> Randy Rettberg and I, both at BBN, took the TCP/Unix challenge.  We
> were both Unix neophytes.  After figuring out what we could (Lion's
> notes were a great help), we still didn't see any clean way to
> construct the common kinds of network programs inside the Unix
> environment.  In particular, it didn't seem possible to write a
> program that could serve a duplex information flow, where you couldn't
> predict from which direction the next piece of data would come.  I.E.,
> when the program was ready to go into an idle state and wait for more
> work to do, you could issue a "read" call to the kernel, specifying a
> file descriptor, and it would hang until data was available from that
> "file".  But if you picked the "wrong" fd to wait on for input, your
> program would wait forever.  How would a "telnet" program, for
> example, know whether its local human user would type another
> character next, or its remote partner across the net would send the
> next character for output to that user terminal.   There may have been
> a way to do this in Unix of the era, but we neophytes couldn't see it.
> Networking didn't seem to fit the Unix "concatenation of pipes"
> paradigm where input flows unidirectionally to output.

Thanks for the interesting memories.

The bit I quoted above reminded me of a bit of folklore from that era: for full-duplex comms, fork a child, and do opposing unidirectional comms in the parent and child processes. For example, http://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/cmd/net/net.c
I can't remember now what was the usual example of a program that did this; "tip" perhaps, or is that too recent? I also don't know how much the trick was still used as networking became popular.

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20130418/54133374/attachment.html>