[ih] History of Naming on The Internet - is it still relevant?

[Craig Partridge]

My take, having programmed with both.

First, the semantics of communicating over a network are NOT the same as
communicating with a file system.  Indicative are three system calls:
select, and sending discrete messages (e.g. UDP).  These were, for
instance, the features that Unix Streams had to add when they sought to fit
networks into the Unix filesystem model.

Second, the filesystem model doesn't convey the semantics of what you're
doing with a network socket well.  Everything is an ioctl.  One of the
early socket documents had an excellent decision tree that illustrated the
different modalities of network socket that you could create.  For
instance, for TCP, you started with socket and then progressed to bind(),
listen(), accept(), or you progressed to connect(), send()/recv().  People
found that easier to understand than open("/dev/tcp"), ioctl(BIND, ....),
ioctl(LISTEN, ...), ioctl(ACCEPT, ....) [I may have some details wrong here
-- 40 years since I programmed to that API].

Was the socket API too low level -- sure and many folks have written
wrappers on top of it.  But it was less klunky than the filesystem API.

Craig

On Thu, Aug 14, 2025 at 8:00 AM John Day <jeanjour at comcast.net> wrote:

> I apologize for bring up this topic after it has been quiet for a couple
> of weeks. It sparked my interest, but it was the end of the summer session
> and I got swamped with all of that.
>
> Why do several of you (apparently all) find the Sockets API so good? This
> was really surprising.
>
> For me, it is one of the 2 or 3 Internet standards (is it really? or just
> what everyone uses?) that has done the most damage to the Internet
> architecture.
>
> It exposes far too much to the application. It has very little of the
> usual properties of an API to create a black box. It requires the
> application to modified to use the Net.  It seems counter to the Unix
> philosophy to make everything look like a file operation.  In fact, when
> the first Unix was put on the Net in 1975, that was the API, something
> like, <file-desc> = OPEN(USCD/Telnet).
> The file-desc would be a form of port-id and could be easily extended for
> other connection specific parameters. There was a meeting at some point to
> discuss what to put into Berkeley Unix but Joy was too taken with Sockets
> to adopt a more Unix-consistent API.
> I have been told that the Microsoft transition to IPv6 was delayed two
> years because every program that used the Net had to be modified.
> A file-oriented API would have allowed a seamless transition to
> Application-names and getting rid of the well-known port kludge. No one
> would have noticed.
>
> Hope I haven’t stirred things up too badly.
>
> Take care,
> John Day
>
> > On Jul 23, 2025, at 23:31, Karl Auerbach via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > On 7/23/25 6:28 PM, Craig Partridge via Internet-history wrote:
> >> On Wed, Jul 23, 2025 at 6:55 PM touch--- via Internet-history <
> >> internet-history at elists.isoc.org> wrote:
> >>
> >>> The user thinks in terms of socket connections; the rest can be opaque.
> >>>
> >> I'd argue that the history of the Internet says that's not quite true.
> >> Users care about the path their traffic takes in the network (various
> >> issues about ensuring certain traffic did not transit certain countries
> >> over the years).   Users care about performance, and before carriers
> sorta
> >> figured out how to ensure good service, we found users playing around
> with
> >> reaching into the routing layer.
> >
> > The socket abstraction has a meritorious aspect: it is simple.
> >
> > But users need ways to express the kind of service that a socket should
> provide.  And, indeed, there are some simple mechanisms for that.
> >
> > But once one digs into the idea of expressing "what kind of service does
> this connection need" things can get complicated really fast.
> >
> > Fred Baker and I worked on the RSVP protocol.  (I did a fairly extensive
> client implementation, Fred the the in-router hooks.) It was hard.  There
> are so many dimensions of "service" ranging from a simple "bit/second rate"
> (over what time span?) to some sort of expression of dynamics (burst
> behavior of the flow).  But even with a reasonably extensive means to
> express connection service RSVP was largely stuck with a relatively limited
> ability to affect actual routing path setup (and re-setup).  And RSVP did
> nothing to help a client chose among multiple equivalent service peers
> (equivalent except for the network path to reach them.)
> >
> > Steve Casner and I were doing network video with potentially many
> separate streams of video and audio from many sources to many
> destinations.  Lip sync was a huge problem.  Beyond the fact that clocks on
> senders and receivers drift with respect to one another, often our code was
> faced with the question "do we pause the stream or do we insert a fig-leaf
> to cover the missing data?"  If the fig leaf got large or frequent that
> coverage could involve switching to an alternative (but equivalent, except
> for the network path) data source.
> >
> > Our code was on top of UDP, which somewhat simplified things. But even
> then we never found a good solution except to ask the providers
> administratively to provision more resources.
> >
> > But sometimes the problem was not the data path itself but rather, the
> client's choice of which (equivalent) server to select (which would imply a
> choice among data paths.)
> >
> > I took the effort further and asked whether we could figure out a way to
> let a client discover an alternative content source, or select among
> multiple potential sources, within a reasonably short period of time (not
> much more than a single round trip time) and without seriously burdening
> the routing fabric or the routers themselves?
> >
> > The method I came up with (circa year 2000) was inspired by Van
> Jacobson's multicast traceroute (mtrace).  I never had a chance to
> implement it in Cisco IOS (I was going to use the on-again/off-again Java
> VM engine that was in some IOS experimental versions.)
> >
> > I used a combination of a hypothetical IP header and an Integrated
> Services T-Spec (RFC 2215) as a means to express the proposed service level.
> >
> > There is a very rough, incomplete draft of the idea up on my website.
> (It was never sufficiently developed even to reach the level of an Internet
> Draft.)
> >
> > Fast Path Characterization Protocol (FPCP)
> >
> > https://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html
> >
> >     --karl--
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> > -
> > Unsubscribe:
> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>
>

-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.