Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site basser.oz
Path: utzoo!linus!philabs!cmcl2!seismo!munnari!basser!boyd
From: boyd@basser.oz (Boyd Roberts)
Newsgroups: net.unix-wizards
Subject: Re: STREAMS query
Message-ID: <459@basser.oz>
Date: Sun, 13-Oct-85 14:13:53 EDT
Article-I.D.: basser.459
Posted: Sun Oct 13 14:13:53 1985
Date-Received: Tue, 15-Oct-85 05:48:45 EDT
References: <471@enmasse.UUCP> <1699@brl-tgr.ARPA> <449@cheviot.uucp> <455@basser.oz> <972@munnari.OZ>
Reply-To: boyd@basser.UUCP (Boyd Roberts)
Organization: Dept. of Comp. Science, Uni of Sydney, Australia
Lines: 57

In article <972@munnari.OZ> kre@munnari.OZ (Robert Elz) writes:

   >Boyd is a little confused - that is, he is confusing sockets & the
   >network code.

Be real.  I may have been drunk, but i wasn't confused.

    >So, probably misinterpreting from Dennis' article, my guess is that
    >Dennis' rlogin would be implemented by having rlogin open /dev/tcpNNN
    >for some NNN, and then doing the regular rlogin protocol (given
    >that tcp is being done for you somewhere).  The problem is, how
    >do I find the NNN.  Its possible that this is some kind of magic
    >device, where two opens of the same name get two completely
    >different connections, in which case all that would be required
    >would be that there be one /dev/tcp000 and everyone would use
    >that.  Is this how its done?  I suspect that its more likely that
    >rlogin has to hunt for a free /dev/tcpNNN somehow though.  The
    >question is, why should rlogin care?  It doesn't need to know
    >any kind of name for its own end of the connection - this is
    >exactly the abstraction that sockets provide.  With a socket, you
    >just "make one" (unnamed) then connect to wherever you want to
    >go (which would also be necessary using the stream approach of
    >course).
    >

Guess again.  You can have a server (a process) that's selecting
on a file /dev/tcp.  Your connector opens /dev/tcp and the connection
is made by the server.  How this works is as follows.

The server is mounted on /dev/tcp and it has a message and a connection line
displine between it and /dev/tcp.  When the other process (call it the
``connector'') opens /dev/tcp the server gets an open message.  The connector
blocks until the the server acknowleges the open.  If server can make the
connection the connector's open returns with a file descriptor that is it's
tcp connection.  On failure, the server nak's the open and you get -1.

The search of /dev/xxNNN was always odious.  

    >There are other problems than rlogin just having to hunt.  What
    >if there aren't enough /dev/tcpNNN's for everyone who wants
    >a connection now?  Just mknod infinity of them?  Seems a little
    >wasteful.

How you make the connection is up to the server (coder).

    >Conclusion - streams seem to be a great idea, but what I would
    >like is the socket interface, and then the ability to push
    >a line discipline (stream?) onto a socket, so I don't need a name
    >for something I am never going to refer to.
    >
    >Incidentally, side issue, can someone comment on whether pipes
    >are implemented using streams in 8th edition unix?

You don't need a name space device to get a stream.  A pipe is
a full duplex stream.  So, call pipe() and you've got a stream.

Boyd Roberts		...!seismo!munnari!basser.oz!boyd