On plan9, you use srv to add the connection as a file to /srv, then mount the file. Mount does not make TCP connections (although srv can call mount for you as a convenience feature).
Multiplexing requires ensuring that tag and fid collisions do not occur, either with coordination or translation tables. I do not believe that the kernel needs this multiplex, as it seems like an uncommon scenario. Why would you mount the same fs twice on the same machine? Also, as you mentioned, a userspace process could handle this easily of needed. Best regards, Kenny Levinsen > On 3. mar. 2016, at 03.09, cigar562hfsp952f...@icebubble.org wrote: > > I recently posted the following to the Inferno mailing list (but > received no response). I'm re-posting here, as this applies to Plan 9 > just as much as to Inferno, anyway... > >> So, I've been looking at the source code of Inferno, and I've noticed >> that, when mount(1) wants to connect to a Styx/9P2000 server on a remote >> machine, it generally opens up a new TCP connection... one for each new >> mount... even if it's just an additional connection to the same service >> on the same remote host. >> >> Recalling the specification for 9P2000, the protocol supports the >> multiplexing of multiple 9P2000 clients/"sessions" onto a single, >> multiplexed, session with the server. In theory, all a 9P2000 >> multiplexer would have to do is map tags and fids so that different >> clients don't use the same values, and negotiate a common version and >> msize in the Tversion/Rversion transactions. All the functionality of >> the protocol, including access control using afids, would be preserved. >> In fact, while complying fully with the 9P2000 specification, it should >> also be possible to multiplex sessions in the REVERSE direction >> (connections from clients on the remote "server" host BACK to servers >> listening on the local "client" host) over the same TCP connection used >> to carry the "forward" (local --> remote) sessions. >> >> I'd assumed, since the protocol allows for this, that this sort of >> multiplexing was done by the Plan 9 and Inferno kernels. Is that not >> the case? And if not, then why not? >> >> To take a stab at answering my own question, I suspect that it might >> have something to do with the Station to Station protocol and SSL setup >> done on a connection prior to exchanging Styx messages. But it seems to >> me that S2S and SSL init could also be multiplexed by the kernel, or >> even transacted over a temporary TCP connection established solely for >> initializing the Styx session. That is to suggest that a client could >> connect directly to a server, execute S2S, close that connection, >> provide the SSL parameters and shared secret to the kernel, then push >> the Styx messages (including any afid) through the kernel multiplexer. >> The kernel could then send the client's Styx messages over the >> multiplexed connection using the SSL parameters specified by the client. >> >> I'd imagine that there could be some latencey issues that might result >> from an approach like this, i.e. if an interactive session were >> conducted over the same connection as a large file transfer. But >> there's nothing to stop a client from establishing its own TCP >> connection (or, at the very least, asking the kernel to allocate a >> second multiplexed connection). Still, multiplexing Styx sessions could >> have some advantages, such as when traversing firewalls where there are >> limits on the number of simultaneous TCP connections or timeouts on >> individual connections. Multiplexing sessions would help "keep alive" >> such TCP connections. It would also help protect encrypted >> communication from traffic analysis. >> >> Now that I've been typing about this for a few paragraphs, it occurs to >> me that a multiplexer like this could probably be implemented as a >> system service running in userspace, without much (if any) extra support >> from the kernel. >> >> So, do Plan 9 or Inferno already do anything like this? If not, do you >> think it would be a smart thing to implement? I'm curious to hear other >> people's thoughts on this. >
