[TUHS] Sockets and the true UNIX

[TUHS] Sockets and the true UNIX

[Ian Zimmerman]

This question is motivated by the posters for whom FreeBSD is not Unix
enough :-)

Probably the best known contribution of the Berkeley branch of Unix is
the sockets API for IP networking.  But today, if for no other reason
than the X/Open group of standards, sockets are the preferred networking
API everywhere, even on true AT&T derived UNIX variants.  So they must
have been merged back at some point, or reimplemented.  My question is,
when and how did that happen?

And if there isn't a simple answer because it happened at different
times and in different ways for each variant, all the better :-)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[TUHS] Sockets and the true UNIX

[Chet Ramey]

On 9/21/17 12:01 PM, Ian Zimmerman wrote:
> This question is motivated by the posters for whom FreeBSD is not Unix
> enough :-)
> 
> Probably the best known contribution of the Berkeley branch of Unix is
> the sockets API for IP networking.  But today, if for no other reason
> than the X/Open group of standards, sockets are the preferred networking
> API everywhere, even on true AT&T derived UNIX variants.  So they must
> have been merged back at some point, or reimplemented.  My question is,
> when and how did that happen?

AT&T merged the sockets interface into SVR4, starting with the BSD code.
Sun did the work.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] Sockets and the true UNIX

[Larry McVoy]

On Thu, Sep 21, 2017 at 09:01:12AM -0700, Ian Zimmerman wrote:
> This question is motivated by the posters for whom FreeBSD is not Unix
> enough :-)
> 
> Probably the best known contribution of the Berkeley branch of Unix is
> the sockets API for IP networking.  But today, if for no other reason
> than the X/Open group of standards, sockets are the preferred networking
> API everywhere, even on true AT&T derived UNIX variants.  So they must
> have been merged back at some point, or reimplemented.  My question is,
> when and how did that happen?
> 
> And if there isn't a simple answer because it happened at different
> times and in different ways for each variant, all the better :-)

I'm pretty sure the two main System V based TCP/IP stacks were STREAMS
based: the Lachman one (which I ported to the ETA-10 and to SCO Unix)
and the Mentat one that was done for Sun.  The socket API was sort of
bolted on top of the STREAMS stuff, you could get to the STREAMS stuff
directly (I think, it's been a long time).

The STREAMS stuff never performed well and the BSD TCP stack or something
like it went into Solaris at some point.  That's another "I think".  If
you want the gory details I'll ask Neal Nuckolls, he would know, he was
in the networking group and worked closely with Mentat.

[TUHS] Sockets and the true UNIX

[David Edmondson]

On Thursday, 2017-09-21 at 09:10:40 -0700, Larry McVoy wrote:

> I'm pretty sure the two main System V based TCP/IP stacks were STREAMS
> based: the Lachman one (which I ported to the ETA-10 and to SCO Unix)
> and the Mentat one that was done for Sun.  The socket API was sort of
> bolted on top of the STREAMS stuff, you could get to the STREAMS stuff
> directly (I think, it's been a long time).

You could pop the socket module to get to the stream underneath, but
lots of streams functionality still works with it present.

dme.
-- 
Modern people tend to dance.

[TUHS] Sockets and the true UNIX

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Thu, Sep 21, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:

>
> The STREAMS stuff never performed well

​Larry is being polite.   It sucked.​

​ It was never designed for it.  dmr designed Streams to replace the tty
handler.   I never understood  why the Summit guys insisted on forcing
networking into it.​



> and the BSD TCP stack or something
> ​ ​
> like it went into Solaris at some point.

​Right.   This is one of the places where SVR4 != Solaris

I was researching a book a long time ago and looked at this.  I had
Solaris, SVR4 and some other stuff at the time.  Like you bit rot has long
set in on the details, but I do remember that the primary thing that
Solaris had was support for Sun's threading model and the networking code
had to be a first class citizen ​or it was not going to scale.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170921/2fdf86f8/attachment.html>

[TUHS] Sockets and the true UNIX

[Larry McVoy]

On Thu, Sep 21, 2017 at 12:25:13PM -0400, Clem Cole wrote:
> On Thu, Sep 21, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> >
> > The STREAMS stuff never performed well
> 
> ???Larry is being polite.   It sucked.???
> 
> ??? It was never designed for it.  dmr designed Streams to replace the tty
> handler.   I never understood  why the Summit guys insisted on forcing
> networking into it.???

+1 

I've always tried to make it clear that dmr's streams != Sys V STREAMS.
I thought dmr streams were cool, I detest the Sys V STREAMS.

[TUHS] Sockets and the true UNIX [ actually carping about streams ]

[Jon Steinhart]

Clem Cole writes:
> dmr designed Streams to replace the tty handler.

I have never had any reason to dig into the streams code.  But there is one
part of the implementation that I hate, which is the way that data is lost
when switching between modules.  This most notably rears its ugly head when
using something like vi, hitting control-Z, and then typing a shell command.
The user has to pause because incoming characters get tossed when switching
from cbreak to cooked.  This has become less of an issue as machines have
gotten faster, but it still gets me if my system is extremely heavily loaded.

Jon

[TUHS] Sockets and the true UNIX

[Chet Ramey]

On 9/21/17 12:10 PM, Larry McVoy wrote:

> I'm pretty sure the two main System V based TCP/IP stacks were STREAMS
> based: the Lachman one (which I ported to the ETA-10 and to SCO Unix)
> and the Mentat one that was done for Sun.  The socket API was sort of
> bolted on top of the STREAMS stuff, you could get to the STREAMS stuff
> directly (I think, it's been a long time).

Here's an article describing the work Sun did (whether it started at Mentat
or not) to initially provide the socket interface on SVR4:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.7181&rep=rep1&type=pdf

It was my impression that they started with the BSD kernel implementation
and used it to create `socklib' and `sockmod'.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] Sockets and the true UNIX

[Jon Steinhart]

Ian Zimmerman writes:
> This question is motivated by the posters for whom FreeBSD is not Unix
> enough :-)
> 
> Probably the best known contribution of the Berkeley branch of Unix is
> the sockets API for IP networking.  But today, if for no other reason
> than the X/Open group of standards, sockets are the preferred networking
> API everywhere, even on true AT&T derived UNIX variants.  So they must
> have been merged back at some point, or reimplemented.  My question is,
> when and how did that happen?
> 
> And if there isn't a simple answer because it happened at different
> times and in different ways for each variant, all the better :-)

Maybe this is naive of me, but I have never liked parts of the sockets
interface.  I understand that at some level it was a political/legal
keeping the networking code independent of the rest of the kernel.
From a technical and historical standpoint, I view it as the tip of
the iceberg bloating the number of system calls.

In particular, I have often thought that it would have been a better
and more consistent with the philosophy to have it implemented as
open("/dev/tcp") and so on.  Granted that networking added some new
functionality that justified some of the system calls, just not socket().

Comments?

Jon

[TUHS] Sockets and the true UNIX

[Larry McVoy]

On Thu, Sep 21, 2017 at 09:13:38AM -0700, Jon Steinhart wrote:
> Maybe this is naive of me, but I have never liked parts of the sockets
> interface.  I understand that at some level it was a political/legal
> keeping the networking code independent of the rest of the kernel.
> >From a technical and historical standpoint, I view it as the tip of
> the iceberg bloating the number of system calls.
> 
> In particular, I have often thought that it would have been a better
> and more consistent with the philosophy to have it implemented as
> open("/dev/tcp") and so on.  Granted that networking added some new
> functionality that justified some of the system calls, just not socket().

If you look in the lmbench code I sort of had similar thoughts but did
them as functions.  I've never been fond of the socket API though I
am sympathetic, it's easy to do the easy parts as /dev/tcp but as I
recall there are all sorts of weird cases that don't fit.  I've tried
to come up with a /dev/tcp style that covers all the cases and I failed.

lib_tcp.h
#include        <sys/types.h>
#include        <sys/socket.h>
#include        <netinet/in.h>
#include        <netdb.h>
#include        <arpa/inet.h>

int     tcp_server(int prog, int rdwr);
int     tcp_done(int prog);
int     tcp_accept(int sock, int rdwr);
int     tcp_connect(char *host, int prog, int rdwr);
void    sock_optimize(int sock, int rdwr);
int     sockport(int s);
#ifndef NO_PORTMAPPER
u_short pmap_getport(struct sockaddr_in *addr, u_long prognum, u_long versnum,
u_int protocol);
bool_t  pmap_set(u_long prognum, u_long versnum, u_long protocol, u_short port);
bool_t  pmap_unset(u_long prognum, u_long versnum);
#endif

[TUHS] Sockets and the true UNIX

[Chris Torek]

>... I've never been fond of the socket API though I
>am sympathetic, it's easy to do the easy parts as /dev/tcp but as I
>recall there are all sorts of weird cases that don't fit.

There's no reason it could not be done literally with entries
similar to /dev ones, since each socket() takes some arguments
(domain, type, protocol) which could be represented as directly
as:

    /socket/domain/type/protocol_or_default

for instance.  For the typical s = socket(PF_INET, SOCK_STREAM, 0)
you would open "/socket/inet/stream/tcp".  To distinguish
between UDP and RDP you'd open "/socket/inet/dgram/udp" vs
"/socket/inet/dgram/rdp".  Of course these days there's a
<type> constant for reliable datagram, and some of these are
just overcomplicating things: /socket/inet/tcp, /socket/inet/icmp,
etc., would actually suffice, but there's an obvious one
to one mapping from "socket" arguments to strings under
"/socket" or whatever top level name you want.

More fundamentally, a socket itself is only "half initialized".
It's neither bound to any local address, nor connected to any
remote address.  The BSD kernel interface introduced two
system calls, bind() and connect(), to let you specify these
two halves.  But these two calls are wrong!  It needs to be
*one* call, that does both operations simultaneously, so as to
allow you to specify that you want the system to provide the
local or remote address.  You supply one or both.  To supply
only one, pass in a NULL for the other one.

 * You supply only the remote address: "I want to connect to
   someone and I know their address, so just pick a local one
   that works."  This is currently written as connect().

 * You supply only the local address: "I want to be a server."
   This is currently written as bind() followed by listen()
   followed by a series of accept()s.  There's no reason for
   a separate listen() call (it takes a "backlog" argument but
   in practice everyone defaults it and the kernel does strange
   manipulations on it.)  This also knocks out the need for
   SO_REUSEADDR, because the kernel can tell at the time of
   the call that you are asking to be a server.  Either someone
   else already is (error) or you win (success).

 * You supply both halves at the same time.  (This is the
   special case FTP requires.)  "I want to connect to someone
   and I know he expects me to be address <L>.")

   This is a rare special case.  We need a way to reserve an
   address.  But it's rare, let's make *it* the complicated one.

   If you supply both halves at the same time, you can pass
   pointers to two all-zero addresses, both local and remote.
   This is different from passing in a NULL ("I don't care"): it
   means "I do care, get me an address" (reserving it) along with
   "I can't actually connect yet".

   Now you have the "3/4ths done" socket.  You know what your
   local address will be.  You give this to the remote, and
   call the system call again with the other guy's IP address
   this time.

   That's not optimal (sometimes the local address you want to
   use depends on the remote address you will use), but it's what
   the existing system calls give you anyway, as you can't call
   connect() first, you must call bind() first.

Also, the profusion of system calls (send, recv, sendmsg, recvmsg,
recvfrom) is quite unnecessary: at most, one needs the equivalent
of sendmsg/recvmsg.

So we could right away do this:

   bind(), listen(), connect()     =>     setconn()
   send(), sendmsg()               =>     sendmsg()
   recv(), recvfrom(), recvmsg()   =>     recvmsg()

even without figuring out how to properly implement /dev/tcp
or whatever.

Of course, it's a bit late. :-)

Chris

[TUHS] Sockets and the true UNIX

[Bakul Shah]

On Thu, 21 Sep 2017 09:13:38 -0700 Jon Steinhart <jon at fourwinds.com> wrote:
Jon Steinhart writes:
> 
> Maybe this is naive of me, but I have never liked parts of the sockets
> interface.  I understand that at some level it was a political/legal
> keeping the networking code independent of the rest of the kernel.
> >From a technical and historical standpoint, I view it as the tip of
> the iceberg bloating the number of system calls.

In a sense the socket interface is a lower level interface
compared to other syscalls. But complicated by the fact that
it tries to be general.

> In particular, I have often thought that it would have been a better
> and more consistent with the philosophy to have it implemented as
> open("/dev/tcp") and so on.  Granted that networking added some new
> functionality that justified some of the system calls, just not socket().

This is more or less how plan9 networking is done.  Among
other things you can write scripts that can do networking even
though the shell knows nothing about networking.  See
    http://doc.cat-v.org/plan_9/4th_edition/papers/net/

The key is to realize that each protocol defines its own
namespace so this fits naturally in plan9.  Allowing services
(programs, kernel or drivers) to define their own namespaces
and making them accessible via a tiny interface to any program
is the main invention of plan9.  Similarly ctl files instead
of ioctls.

[TUHS] Sockets and the true UNIX

[Steve Simon]

sockets and streams, but what about tli (i think) transport level interface - that exists in one of the sys-v variants.

maybe that was streams and i just didn't realise or maybe it was something else?

-Steve


> On 21 Sep 2017, at 19:56, Bakul Shah <bakul at bitblocks.com> wrote:
> 
>> On Thu, 21 Sep 2017 09:13:38 -0700 Jon Steinhart <jon at fourwinds.com> wrote:
>> Jon Steinhart writes:
>> 
>> Maybe this is naive of me, but I have never liked parts of the sockets
>> interface.  I understand that at some level it was a political/legal
>> keeping the networking code independent of the rest of the kernel.
>>> From a technical and historical standpoint, I view it as the tip of
>> the iceberg bloating the number of system calls.
> 
> In a sense the socket interface is a lower level interface
> compared to other syscalls. But complicated by the fact that
> it tries to be general.
> 
>> In particular, I have often thought that it would have been a better
>> and more consistent with the philosophy to have it implemented as
>> open("/dev/tcp") and so on.  Granted that networking added some new
>> functionality that justified some of the system calls, just not socket().
> 
> This is more or less how plan9 networking is done.  Among
> other things you can write scripts that can do networking even
> though the shell knows nothing about networking.  See
>    http://doc.cat-v.org/plan_9/4th_edition/papers/net/
> 
> The key is to realize that each protocol defines its own
> namespace so this fits naturally in plan9.  Allowing services
> (programs, kernel or drivers) to define their own namespaces
> and making them accessible via a tiny interface to any program
> is the main invention of plan9.  Similarly ctl files instead
> of ioctls.

[TUHS] Sockets and the true UNIX

[Bakul Shah]

On Sep 21, 2017, at 12:13 PM, Steve Simon <steve at quintile.net> wrote:
> 
> sockets and streams, but what about tli (i think) transport level interface - that exists in one of the sys-v variants.
> 
> maybe that was streams and i just didn't realise or maybe it was something else?

Never played with TLI. Not a sys-v fan.

[TUHS] Sockets and the true UNIX

[ron minnich]

you can go back and find an early RFC which discusses the notion of
/dev/tcp etc. I think I referenced it the last time this question came up.

In that rfc, the idea of /dev/tcp and so on was advanced. To connect to
harv, one might create /dev/tcp/harv, for example. It was not quite right.
How do you name a port? What file system operation in Unix corresponds to
what socket operation? There were lots of efforts from 77 or so on to get
sockets APIs done in a Unix style, i.e. not the style we ended up with, but
AFAIK nobody really worked it out until Plan 9 did it.

While it is true that socket()/bind/listen/accept/connect have stood the
test of time, I know when they were introduced many people thought of that
API as the first break in the Unix model, and a wrong turn, one that was
never fixed.

It's very easy to create a "file system" model for the network in a way
that doesn't make sense, e.g. if I have /dev/tcp/harv, and mv it to
/dev/tcp/prep, does that mean I close the connection to harv and open one
to prep? And so on. These issues were covered really nicely in a talk Rob
Pike gave in the 90s, but I can't find those slides any more and neither
can he. They're probably still on the venti server in the Unix room ... :-)

For an example of (IMHO) not getting it right, see:
http://www.cs.vu.nl/~herbertb/papers/osreview2008-2.pdf

I think anyone looking to put something like a network stack in the name
space should study on what Plan 9 did, not because it's the "right" or
"only' way to do it, but it's a way that worked.

But overall, in the 1977 timeframe, when (IIRC) there were no synthetic
file systems, I think we did not know how to think about "networks in the
file system" and we got what we got. By the time it was worked out, well,
it was too late to change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170921/143613a4/attachment.html>

[TUHS] Sockets and the true UNIX

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

On Thu, Sep 21, 2017 at 4:15 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
>
> In that rfc, the idea of /dev/tcp and so on was advanced. To connect to
> harv, one might create /dev/tcp/harv, for example. It was not quite right.
> How do you name a port?
>
​The way we did in an early version was a crude hack in the nami.​
 /dev/tcp/
​host/opt1,opt2,opt3...
 It turns out nami left the unparsed chars alone and you could reach over
and grab them.  So after
/dev/tcp
was called the rest of the code did the work.   IIRC, Apollo Domain did
something similar as did the ChaosNet code.

The sockets stuff was something Joy created to compete with the CMU Accent
networking system.  Remember CSRG did not have the responsibility to
support networking on UNIX, BBN did.  The IP/TCP stack had been developed
by Gurwitz et al at BBN and did use the open/close/ioctl interface.    CMU
was developing Accent on the Triple Drip PascAlto (aka the Perq) and had a
formal networking model that was very clean and sexy.  There were a lot of
people interested in workstations, the Andrew project (MIT is about to
start Athena etc).   So Bill creates the sockets interface, and to show
that UNIX could be just as modern as Accent.

​He puts the BBN stack behind the interface.​   When 4.2 ships, no one
remembers the BBN API, it is th API that lived.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170921/4bab3a14/attachment.html>

[TUHS] Sockets and the true UNIX

[Dave Horsfall]

On Thu, 21 Sep 2017, Jon Steinhart wrote:

> In particular, I have often thought that it would have been a better and 
> more consistent with the philosophy to have it implemented as 
> open("/dev/tcp") and so on.  Granted that networking added some new 
> functionality that justified some of the system calls, just not 
> socket().

An old Unix manual referred to preferring "/dev/net" but that would've 
been a 9-track even parity tape drive under the nomenclature at the 
time...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."