From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: From: Skip Tavakkolian Date: Tue, 3 Feb 2015 13:18:08 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113943cae771d7050e2ee672 Subject: Re: [9fans] 9p2000 agent supporting multiple clients on a single connection Topicbox-Message-UUID: 3f9193f0-ead9-11e9-9d60-3106f5b1d025 --001a113943cae771d7050e2ee672 Content-Type: text/plain; charset=UTF-8 fcp in plan 9 and 9pserve in p9p On Tue Feb 03 2015 at 3:35:07 AM Giacomo Tesio wrote: > 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 > --001a113943cae771d7050e2ee672 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable fcp in plan 9 and 9pserve in p9p


On T= ue Feb 03 2015 at 3:35:07 AM Giacomo Tesio <giacomo@tesio.it> wrote:
<= div dir=3D"ltr">While reading intro(5) I noticed these very interesting lin= es:

Fids are chos=
en 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.
<= 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.
If available, I'd really = like to read such code.

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?

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

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


Giacomo
--001a113943cae771d7050e2ee672--