From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60706221446n2645b7f4ncd00b2bb177b837c@mail.gmail.com> Date: Fri, 22 Jun 2007 14:46:03 -0700 From: "David Leimbach" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] About 9P ... In-Reply-To: <467C4095.3040506@free.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_112939_6089665.1182548763507" References: <46783873.4060804@free.fr> <20070622013243.B21140@mrwint.cisco.com> <467B72FC.2020808@free.fr> <20070622165754.D21140@mrwint.cisco.com> <467C31EB.1060302@free.fr> <3e1162e60706221410l20d22b87had1497198b60abe7@mail.gmail.com> <467C4095.3040506@free.fr> Topicbox-Message-UUID: 85ac4148-ead2-11e9-9d60-3106f5b1d025 ------=_Part_112939_6089665.1182548763507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 6/22/07, Philippe Anel wrote: > > David Leimbach a =E9crit : > > Transactions are tagged right? So you can, in fact, have many in > > flight at once. > > > > Perhaps I'm missing what you meant by pipelined. > I meant sending a couple of requests on one fid before receiving > replies. That I believe is correct, there's no guarantee that a server has to proces= s your requests on a single fid in the order the requests are sent/received. It will eventually reply to your requests in some order, and you'll be able to tell what order they occurred since I believe 9p requires a transport guaranteeing the sequence sent will be the sequence received. (I'm a 9p amateur though) Yes transaction are tagged, this doesn't mean that requests are > serialized (processed in order). > > See the example sent by Derek : > > 1 send: open,fid,file > 2 send: read,fid,args > 3 send: read,fid,args > > (wait one rtt) > > 4 recv: open success/fail > 5 recv: read result / read error due to unknown fid > 7 recv: read result / read error due to unknown fid > > I see no reason for the server to not reply the 2nd request > before the 1st one : by example the server can receive all > the requests and distpach those reqs to different tasks. Well you may have a point, but why not 1. send: open, fid, file 2. wait for reply to 1. 3. send read, fid, args 4. send read, fid, args 5. wait for either... 6. wait for remaining? At that point you're still pipelining, and since you're reading presumably into separate buffers, or different locations in the same buffer, who cares about the order? > Because all transactions are tagged ... this wouldn't break > 9P. However, this doesn't work as expected. Depends on what's expected :-) That's why I think 9P was not designed to allow this. But > maybe I'm wrong. It's probably designed to allow what I just said, you can sequence some operations, but then things that don't need to be sequenced could be pipelined. Different servers may behave differently, 9P makes no guarantee AFAIK. Dave Phil; > > > --=20 - Passage Matthew 5:37: But let your communication be, Yea, yea; Nay, nay: for whatsoever is mor= e than these cometh of evil. ------=_Part_112939_6089665.1182548763507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 6/22/07, Philippe Anel <xigh@free.fr<= /a>> wrote:
David Leimbach a =E9crit :
> Transactions are tagged right? &nbs= p;So you can, in fact, have many in
> flight at once.
>
>= Perhaps I'm missing what you meant by pipelined.
I meant sending a = couple of requests on one fid before receiving
replies.

=

That I believe is co= rrect, there's no guarantee that a server has to process your requests = on a single fid in the order the requests are sent/received.

It will eventu= ally reply to your requests in some order, and you'll be able to tell w= hat order they occurred since I believe 9p requires a transport guaranteein= g the sequence sent will be the sequence received.  (I'm a 9p amat= eur though)
 

Yes tran= saction are tagged, this doesn't mean that requests are
serialized (= processed in order).

See the example sent by Derek :

1   send: open,fid= ,file
2   send: read,fid,args
3   send: read,fid,= args

    (wait one rtt)

4   rec= v: open success/fail
5   recv: read result / read error due to= unknown fid
7   recv: read result / read error due to unknown fid

= I see no reason for the server to not reply the 2nd request
before the 1= st one : by example the server can receive all
the requests and distpach= those reqs to different tasks.

Well yo= u may have a point, but why not

1. send: open, fid, file
2. wait for reply to 1.
3. send read, fid, args
4. send read, fid, args
<= div>5. wait for either...
6. wait for remaining?

At that point you're still = pipelining, and since you're reading presumably into separate buffers, = or different locations in the same buffer, who cares about the order?

 
Because = all transactions are tagged ... this wouldn't break
9P. However, thi= s doesn't work as expected.


Depends on what's expected := -)
 

That's why I think 9P was not designed to allow this. But
maybe I= 9;m wrong.


It's probably desi= gned to allow what I just said, you can sequence some operations, but then = things that don't need to be sequenced could be pipelined.

Different serv= ers may behave differently, 9P makes no guarantee AFAIK.

Dave
 

Phil;





--
- Pass= age Matthew 5:37:
   But let your communication be, Yea, yea; = Nay, nay: for whatsoever is more than these cometh of evil. ------=_Part_112939_6089665.1182548763507--