From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <150029e986ff7e10958868a983ff9794@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue, 21 Apr 2009 12:25:00 -0400
To: 9fans@9fans.net
In-Reply-To: <20090421161033.170FD5B24@mail.bitblocks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Plan9 - the next 20 years
Topicbox-Message-UUID: edd8cd98-ead4-11e9-9d60-3106f5b1d025

> > 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.

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

- erik