From: cigar562hfsp952fans@icebubble.org
To: 9fans@9fans.net
Subject: [9fans] Fwd: Multiplexing Styx/9P2000 over TCP connections
Date: Thu, 3 Mar 2016 02:09:57 +0000 [thread overview]
Message-ID: <8660x4tiq2.fsf@cmarib.ramside> (raw)
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.
next reply other threads:[~2016-03-03 2:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 2:09 cigar562hfsp952fans [this message]
2016-03-03 9:08 ` Kenny Lasse Hoff Levinsen
2016-03-03 15:32 ` Charles Forsyth
2016-03-03 16:04 ` Charles Forsyth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8660x4tiq2.fsf@cmarib.ramside \
--to=cigar562hfsp952fans@icebubble.org \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).