From mboxrd@z Thu Jan  1 00:00:00 1970
References: <8660x4tiq2.fsf@cmarib.ramside>
From: Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <8660x4tiq2.fsf@cmarib.ramside>
Message-Id: <18809CD3-1CC2-4AB5-BFFA-2658E54A3B92@gmail.com>
Date: Thu,  3 Mar 2016 10:08:05 +0100
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: [9fans] Fwd: Multiplexing Styx/9P2000 over TCP connections
Topicbox-Message-UUID: 89de41e2-ead9-11e9-9d60-3106f5b1d025

On plan9, you use srv to add the connection as a file to /srv, then mount th=
e 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, eit=
her with coordination or translation tables. I do not believe that the kerne=
l 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 user=
space process could handle this easily of needed.

Best regards,
Kenny Levinsen

> On 3. mar. 2016, at 03.09, cigar562hfsp952fans@icebubble.org wrote:
>=20
> 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...
>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>=20