← Back to context

Comment by lizknope

7 hours ago

Why did BSD make Unix sockets something outside of the file system?

I can do this in bash but I always thought it would be more elegant to do a similar thing in C. I thought Plan 9 handled it more like this?

cat < /dev/tcp/localhost/22

SSH-2.0-OpenSSH_10.0

They did not have the original unix vision. and it is a lot easier to to design an interface as a programming interface than shoehorn it into a filesystem interface.

I think having a filesystem interface is pretty great, and plan9 showed it could be done. but having to describe all your io in the [database_key, open(), close(), read(), write(), seek()] interface. can be tricky and limiting for the developer. It is pretty great for the end user however. Having a single api for all io is a super power for adaptive access patterns.

I think the thing that bothers me the most about the bsd socket interface is how close it is to a fs interface. connect()/bind() instead of open(), recv()/send() instead ot read()/write() but it still uses file discripters so that stuff tends to work the same. We almost had it.

As much as I like BSD and as great an achievement that the socket interface was, I still think this was their big failure.

  • I just think this sounds very elegant

    https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#/net

    > Plan 9 does not have specialised system calls or ioctls for accessing the networking stack or networking hardware. Instead, the /net file system is used. Network connections are controlled by reading and writing control messages to control files. Sub-directories such as /net/tcp and /net/udp are used as an interface to their respective protocols.

    > Combining the design concepts

    > Though interesting on their own, the design concepts of Plan 9 were supposed to be most useful when combined. For example, to implement a network address translation (NAT) server, a union directory can be created, overlaying the router's /net directory tree with its own /net. Similarly, a virtual private network (VPN) can be implemented by overlaying in a union directory a /net hierarchy from a remote gateway, using secured 9P over the public Internet. A union directory with the /net hierarchy and filters can be used to sandbox an untrusted application or to implement a firewall.[43] In the same manner, a distributed computing network can be composed with a union directory of /proc hierarchies from remote hosts, which allows interacting with them as if they are local.

    > When used together, these features allow for assembling a complex distributed computing environment by reusing the existing hierarchical name system

    I remember first setting up NAT or IP masquerading around 1998. It seemed like an ugly hack and some custom protocols did not work.

    I use a bunch of VPNs now and it still seems like a hack.

    The Plan 9 way just seems very clean although you now have to secure the server more strongly because you are exporting filesystems from it and others are mounting it.

    • > The Plan 9 way just seems very clean although you now have to secure the server more strongly because you are exporting filesystems from it and others are mounting it.

      With that I mind I wish (the standard Unix gripe!) 9P had a more complex permissions model... 9P's flexibility and per-process namespaces get you a long way, but it's not a natural way to express them.

  • > can be tricky and limiting for the developer. It is pretty great for the end user however.

    This seems to be a great general principle of api design! The best apis are those that are hated by the developer and loved by the end users.

    • > The best apis are those that are hated by the developer and loved by the end users.

      No, just those loved by the API consumer. Negative emotions on one end doens't do anything positive.

      In the case of plan9, not everything can be described elegantly in the filesystem paradigm and a lot of things end up having really awkward "ctl" files which you write command strings to that the fileserver needs to parse. It also handicaps performance due to the number of filesystem operation roundtrips you usually end up making.

      Maybe if combined with something io_uring-esque, but the complexity of that wouldn't be very plan9-esque.

      2 replies →