> you open /net/tcp/clone to reserve a connection, and read the connection ID from it. Then you open /net/tcp/n/ctl and write "connect 127.0.0.1!80"
This feels so ham fisted to me. Why not just open /net/tcp/127.0.0.1/80? I am sure there are reasons, but if the goal is to make everything a file, this feels like a more natural representation.
The ctl file also lets you control other connection settings, such as keep alive. It would also be unfortunate to run ls in /net/tcp and dump the entire IPv4/6 space into your terminal.
Not sure I buy that last sentence. Why would the system populate these directories with anything other than a) what’s configured to be assigned to the system, and b) what the caller requests to be created by simply opening a specific path?
Sure, you could script opening each address of the entire address space and have an unfortunate situation, but you don’t get that by default when you simply query what exists.
That said, it’s been a veeeery long time since I tried out Plan9 and Inferno.
> The ctl file also lets you control other connection settings, such as keep alive.
Yes, though this could have been achieved with a bunch of sysfs-like entries under /net/tcp/127.0.0.1/80/<port>/ with the added benefit of being easily discoverable.
> It would also be unfortunate to run ls in /net/tcp and dump the entire IPv4/6 space into your terminal.
A reasonable semantics here would be to only list hosts to which there are active connections.
Probably so that you could also write additional options for connections, the same way you would with setsockopt. Besides, using connection IDs, and thus having a more or less persistent filename for the current connection, makes it easier for several programs to use the same connection.
I never saw what the Bell Labs folks had against Berkeley sockets, aside from them being from Berkeley and not Bell Labs. It's a crufty interface either way, because you can't shove all the complexity under the rug.
They're optimizing for as few syscalls as possible, I suppose, but in Plan 9 you still create pipes with pipe(), not by writing to a special file. And if you already have pipe(), why not socket()?
The TLI/XTI t_open() call takes a path to a character device to identify the desired protocol, instead of a bunch of numbers like BSD socket() does. Isn’t the former approach both more Unix-like and more elegant-and also more extensible? Supporting new protocols, multiple TCP/IP stacks - all easily achievable just by creating a different device driver and telling the app to open a different path (or even using something like a mount namespace to make the hardcoded path go to a different device for each app.) With Berkeley sockets it isn’t clear how to achieve that.
Even if each connection has the same remote IP address + TCP port, it has a distinct local port. What you get back from opening /net/tcp/clone is essentially a directory name, with the local port as a file name in it, along with a few more files representing various attributes of interest.
Yeah, the filesystem has no "array append" operation, it's usually hamfisted into place by writing to a special key in the dictionary. Having a native fs op for "append to dir" would solve some small level of Plan 9 awkwardness...
But now there isn't a path to represent that specific connection we just opened, and there is no way to open it again, say from within another process. The only handle for the open connection you have is the FD, and you'd have to send that around which is harder (but also safer I admit).
The approach would be Linux-y but probbly not enough according to 9p standards.
This feels so ham fisted to me. Why not just open /net/tcp/127.0.0.1/80? I am sure there are reasons, but if the goal is to make everything a file, this feels like a more natural representation.