From mboxrd@z Thu Jan  1 00:00:00 1970
From: cigar562hfsp952fans@icebubble.org
To: 9fans@9fans.net
Date: Thu,  3 Mar 2016 02:09:57 +0000
Message-ID: <8660x4tiq2.fsf@cmarib.ramside>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [9fans] Fwd: Multiplexing Styx/9P2000 over TCP connections
Topicbox-Message-UUID: 89d5cb70-ead9-11e9-9d60-3106f5b1d025

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.