Re: [9fans] About 9P ...

["Francisco J Ballesteros" <nemo@lsub.org>]

It would be fine to just use the same tag as suggested by Russ ans Sape
if you just happen to have several 9P requests that you know that have
to be issued
to serve a particular call. For example, say you add a library
function (or syscall)
get(),
you could send Twalk tag3 nfid F Topen fid F, Tread fid F, Tread fid F, ....
all with the same tag, without waiting for replies, and the server,
knowning they have
the same tag, would sever Topen, Tread, ... only if Twalk worked. That
would batch
all the requests, as intended.

Now, say you have a program that does:
if (stat(afile)){
   open(afile)
   read(afile)
   close(afile)
}

By the time of the stat you could have read the initial part of the
file along with its
metadata (maybe the entire file!, if it's small). Also, some other
program might be using
the same file, and you'd send the RPCs on its behalf.

If instead of changing the protocol, you use intermediate processes
that do this "caching",
this is what happens:

by the time of the stat, the process does a get (even if it has a
cache entry for the file, to
check for cache validity). That get, retrieves initial data for the file.

Because the entry is known valid, any call to read bytes (and any stat
done by any other
process in the mean time) would be served from the local process, no
further RPCs.

In particular, the open() above would use the entry in the cache and
would not walk to the file again. This does not hurt (much) coherency.
Suppose the file was removed after open,
you cannot tell if what happen is that it was removed after read
(going to the server to do the
read) or what happen is that it was removed after open (and data was
served from the the
data just read during open, or during stat).

As this caching thing changes the semantics quite a bit, it seemed ok
to use the simplest
protocol that we could imagine that would implement such behaviour,
instead of batching
9p requests just to have 9p on the wire.

Note that having two programs <file calls> <-> op  and op <-> styx
means that nobody
but these two programs has to be aware of the new protocol. It's
buried deep in the
bad latency communications link, and everyone else thinks that styx is
the protocol spoken
everywhere.

Again, if anyone sees anything wrong if this approach, even though
it's already implemented
and seems to be working fine, I'd love to find out a better way.



On 6/23/07, Uriel <uriel99@gmail.com> wrote:
> I thought russ (and charles and sape?) proposed a good solutions to
> the latency issues in 9P at IWP9. Actually as far as I can remember it
> was the only change to 9P that was accepted as justified.
>
> My memory is bad, probably got the details wrong but I think there
> were two approaches: one by allowing multiple requests with the same
> tag to be grouped, and another with an extra flag filed that indicates
> if more messages in a group are on their way.
>
> I still don't understand what could be wrong with either approach (but
> again, I don't even remember the details of either) and why nemo had
> to invent yet another protocol. Maybe someone can enlighten my usual
> ignorance.
>
> uriel
>
> On 6/23/07, erik quanstrom <quanstro@coraid.com> wrote:
> > > 9P is just great for use when latency is reasonable (or not too bad,
> > > with cfs), but to go further
> > > away and still be comfortable using remote files, I'd say we need
> > > another protocol.
> > > I'd love to be proved wrong :)
> >
> > are there any protocols that deal well with latency?
> >
> > the only way i know to deal with latency is to do some
> > sort of tagged queueing.  (perhaps i don't know enough
> > computer history.)  unfortunately, this doesn't
> > work if part of the data you need depend on some
> > prior part; a conversation means ping-pong communication.
> >
> > the great news for 9p is that latency is decreasing.  in
> > /sys/doc/net/net.ps, the IL/ether latency is listed as
> > having a latency of 1420µs.  my home fileserver
> > has a 57µs latency to my cpu server. (the fileserver is a
> > pIII with a $19 rtl8169.)
> >
> > even custom Cyclone interface between the file server and
> > the cpu server is listed as having a latency of 375µs.
> >
> > let's hope the same holds true for wireless networking.
> >
> > - erik
> >
>