From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amol Dixit To: "9fans@9fans.net" <9fans@9fans.net> Date: Tue, 21 Jan 2014 15:00:51 -0800 Message-ID: <66EC9842-1F95-40F9-8765-E4C948BD2738@vmware.com> References: In-Reply-To: Content-Type: multipart/alternative; boundary="_000_66EC98421F9540F98765E4C948BD2738vmwarecom_" MIME-Version: 1.0 Subject: Re: [9fans] Duplicate fids on 9p server Topicbox-Message-UUID: b421b8c2-ead8-11e9-9d60-3106f5b1d025 --_000_66EC98421F9540F98765E4C948BD2738vmwarecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Charles. Interestingly, I had read your paper and was my primary ref= erence so far (The Ubiquitous File Server). Like you said the way to handle this is to maintain open fids as per-client= state - it worked. I noticed linux/v9fs also does something similar, altho= ugh it is not a 9P server per se. At some point in future, I would like to = understand how in the case of clients sharing a single connection, the =93a= gent managing the sharing arranges that no two clients chose the same fid= =94. Amol Charles Forsyth charles.forsyth at gmail.com wrote: see intro(5): "All requests on a connection share the same fid space" If several clients share one connection, as intro(5) says: "the agent managing the sharing must arrange that no two clients choose the same fid". That happens for instance with many cpu server processes sharing one 9p connection to the file server. That won't apply in your case, unless 9pfuse doesn't distinguish the different connections at the server. It's worth (re)reading the description of the protocol in section 5 of the manual to have a good grasp of the details, even when they are encapsulated by a library such as lib9p. "Basically the server should create new internal fids with ClientID+FID to point to the *same* file ...". You don't see that in (say) ramfs, because it has a single connection (the /srv file), and the kernel correctly manages the fid space for all client processes. Most 9p services are implemented that way. The few existing servers that manage distinct connections (eg, network connections), have per-connection state, and put the fid -> file map in that state. (There isn't any need to have an extra level of "internal fids", just keep a separate map per connection.) In fossil, for instance: struct Con { ... Fid* fidhash[NFidHash]; /* per-connection Fid map */ struct Fid { ... u32int fidno; /* actual 32-bit fid number chosen by client */ Con* con; /* the Fid belongs to one connection */ File* file; /* the Fid points to a File */ On Jan 19, 2014, at 10:49 PM, Amol Dixit > wrote: Hi, I am pretty new to 9P and I was attempting to write a basic file server for= 9P clients. I am using 9pfuse on the client end to connect to my server. I have a quest= ion about *fid* alloction on the server. In the sample server implementation of plan9port lib9p/{ramfs.c, srv.c} =85= the server code returns Edupfid if a particular fid is already used (due t= o attach, walk, open etc). So for a single client, the server works just fine =97 fids are allocated i= n order 0, 1, 2=85 etc. If the second client using 9pfuse tries to attach to this server it will re= quest the same sequence of fids 0, 1, 2=85 and so on. The server code will = immediately reject these requests with Edupfid if those fids are currently = in use. I first assumed the client will correct itself and retry the same request w= ith a new fid. On more thought I realized that the server should be the one= differentiating between the clients even if they request the same fids for= attach/open/walk etc. Am I right in this assumption? Basically the server = should create new internal fids with ClientID+FID to point to the *same* fi= le and maintain that mapping=85.so that all clients (9pfuse based in this c= ase) still see its sequence (0, 1, 2=85), but the server internally maps th= em to a different IDs pointing to the same file. Hope above question makes sense. Thanks in advance, Amol --_000_66EC98421F9540F98765E4C948BD2738vmwarecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks Charles. I= nterestingly, I had read your paper and was my primary reference so far (Th= e Ubiquitous File Server).
Like you said the way to handle this i= s to maintain open fids as per-client state - it worked. I noticed linux/v9= fs also does something similar, although it is not a 9P server per se. At s= ome point in future, I would like to understand how in the case of clients = sharing a single connection, the =93agent managing the sharing arranges tha= t no two clients chose the same fid=94.

Amol
=

Charles Forsyth charles.forsyth at gmail.com  wrote:
see intro(5): "All r=
equests on a connection share the same fid space"

If several clients share one connection, as intro(5) says:
"the agent managing the sharing must arrange that no two clients choose the
same fid".
That happens for instance with many cpu server processes sharing one 9p
connection to the file server.
That won't apply in your case, unless 9pfuse doesn't distinguish the
different connections at the server.

It's worth (re)reading the description of the protocol in section 5 of the
manual to have a good grasp of
the details, even when they are encapsulated by a library such as lib9p.

"Basically the server should create new internal fids with ClientID+FID to
point to the *same* file  ...".

You don't see that in (say) ramfs, because it has a single connection (the
/srv file), and the kernel correctly manages
the fid space for all client processes. Most 9p services are implemented
that way.

The few existing servers that manage distinct connections (eg, network
connections),
have per-connection state, and put the fid -> file map in that state.
(There isn't any need
to have an extra level of "internal fids", just keep a separate map per
connection.)
In fossil, for instance:

struct Con {
    ...
Fid* fidhash[NFidHash];   /* per-connection Fid map */

struct Fid {
    ...
u32int fidno;      /* actual 32-bit fid number chosen by client */

        Con* con;                /* the Fid belongs to one connection */

File* file;                 /* the Fid points to a File */

On Jan 19, 2014, at 10:49 PM, Amol Dixit <amold@vmware.com> wrote:

Hi,
I am pretty new to 9= P and I was attempting to write a basic file server for 9P clients.
I a= m using 9pfuse on the client end to connect to my server. I have a question= about *fid* alloction on the server.

In the sample server implement= ation of plan9port lib9p/{ramfs.c, srv.c} =85 the server code returns Edupf= id if a particular fid is already used (due to attach, walk, open etc). So for a single client, the server works just fine =97 fids are allocated = in order 0, 1, 2=85 etc.
If the second client using 9pfuse tries to atta= ch to this server it will request the same sequence of fids 0, 1, 2=85 and = so on. The server code will immediately reject these requests with Edupfid = if those fids are currently in use.

I first assumed the client will= correct itself and retry the same request with a new fid. On more thought = I realized that the server should be the one differentiating between the cl= ients even if they request the same fids for attach/open/walk etc. Am I rig= ht in this assumption? Basically the server should create new internal fids= with ClientID+FID to point to the *same* file and maintain that mapping=85= .so that all clients (9pfuse based in this case) still see its sequence (0,= 1, 2=85), but the server internally maps them to a different IDs pointing = to the same file.

Hope above question makes sense.

Thanks in = advance,
Amol

= --_000_66EC98421F9540F98765E4C948BD2738vmwarecom_--