On Tue, Apr 21, 2009 at 9:25 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > > if the problem with 9p is latency, then here's a decision that could be
> > > revisisted.  it would be a complication, but it seems to me better than
> > > a http-like protocol, bundling requets together or moving to a storage-
> > > oriented protocol.
> >
> > Can you explain why is it better than bundling requests
> > together?  Bundling requests can cut out a few roundtrip
> > delays, which can make a big difference for small files.
> > What you are talking about seems useful for large files [if I
> > understand you correctly].  Second, 9p doesn't seem to
> > restrict any replies other than Rflushes to be sent in order.
> > That means the server can still send Rreads in any order but
> > if a Tflush is seen, it must clean up properly.  The
> > situation is analogous what happens in an an OoO processor
> > (where results must be discarded in case of exceptions and
> > mis-prediction on branches).
>
> bundling is equivalent to running the original sequence on
> the remote machine and shipping only the result back.  some
> rtt latency is eliminated but i think things will still be largely
> in-order because walks will act like fences.  i think the lots-
> of-small-files case will still suffer.  maybe i'm not quite following
> along.


Perhaps you don't want to use this technique for lots of smaller files.
 There's nothing in the protocol Roger suggested preventing us from using
different sequence id's and getting the old behavior back right?

It's a bit complex... but worth thinking about.

Dave


>
>
> bundling will also require additional agent on the server to
> marshal the bundled requests.
>
> - erik
>
>