From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
Date: Tue,  3 Feb 2015 12:34:51 +0100
Message-ID: <CAHL7psFbqcOFG=8++qVBoKpu+c=JJ_14zwi5BxvTcQNQOTOPLA@mail.gmail.com>
From: Giacomo Tesio <giacomo@tesio.it>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=001a11c2a4a8803f4b050e2d7558
Subject: [9fans] 9p2000 agent supporting multiple clients on a single
	connection
Topicbox-Message-UUID: 3f73bbfa-ead9-11e9-9d60-3106f5b1d025

--001a11c2a4a8803f4b050e2d7558
Content-Type: text/plain; charset=UTF-8

While reading intro(5) I noticed these very interesting lines:

Fids are chosen by
the client.  All requests on a connection share the same fid
space; when several clients share a connection, the agent
managing the sharing must arrange that no two clients choose
the same fid.

And later:

A client can send multiple T-messages without waiting for
the corresponding R-messages, but all outstanding T-messages
must specify different tags.  The server may delay the
response to a request and respond to later ones; this is
sometimes necessary, for example when the client reads from
a file that the server synthesizes from external events such
as keyboard characters.


This is a very interesting feature, allowing a sort of proxing at
connection level.
Such a proxy could accept 9P connections on a socket and forward them to a
remote server (after modifying fids and tags so that they are kept unique),
largely improving scalability.
If available, I'd really like to read such code.

BTW, is there any client library that actually enables consumers to send
multiple T-messages without waiting the corresponding R-messages and then
consume responses when they arrive?

All the 9p implementations that I saw were synchronous, allowing only one
client per connection.


Where can I find an implementation of these features?
I guess it would be a really instructive read.


Giacomo

--001a11c2a4a8803f4b050e2d7558
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While reading intro(5) I noticed these very interesting li=
nes:<div><br></div><div><pre style=3D"margin-left:2em;font-size:1.2em;color=
:rgb(0,0,0);line-height:20.1599998474121px;text-align:justify">Fids are cho=
sen by
the client.  All requests on a connection share the same fid
space; when several clients share a connection, the agent
managing the sharing must arrange that no two clients choose
the same fid.</pre></div><div>And later:</div><div><pre style=3D"margin-lef=
t:2em;font-size:1.2em;color:rgb(0,0,0);line-height:20.1599998474121px;text-=
align:justify">A client can send multiple T-messages without waiting for
the corresponding R-messages, but all outstanding T-messages
must specify different tags.  The server may delay the
response to a request and respond to later ones; this is
sometimes necessary, for example when the client reads from
a file that the server synthesizes from external events such
as keyboard characters.</pre></div><div><br></div><div><div>This is a very =
interesting feature, allowing a sort of proxing at connection level.</div><=
div>Such a proxy could accept 9P connections on a socket and forward them t=
o a remote server (after modifying fids and tags so that they are kept uniq=
ue), largely improving scalability.</div><div>If available, I&#39;d really =
like to read such code.</div><div><br></div><div>BTW, is there any client l=
ibrary that actually enables consumers to send multiple T-messages without =
waiting the corresponding R-messages and then consume responses when they a=
rrive?</div><div><br></div><div>All the 9p implementations that I saw were =
synchronous, allowing only one client per connection.</div><div><br></div><=
div><br></div><div>Where can I find an implementation of these features?</d=
iv><div>I guess it would be a really instructive read.</div><div><br></div>=
<div><br></div><div>Giacomo</div></div></div>

--001a11c2a4a8803f4b050e2d7558--