From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <37cbff0a2270a642562624eceaa0b317@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 9p & read-ahead
From: rog@vitanuova.com
In-Reply-To: <004b01c35748$b8796090$c901a8c0@cc77109e>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Thu, 31 Jul 2003 21:52:57 +0100
Topicbox-Message-UUID: 0d4a5722-eacc-11e9-9e20-41e7f4b1d025

> great for annoying people by streaming video in the unix room.

related to this, i wonder whether anyone is using the following
technique to get around RPC latency overheads when streaming data over
9p:

allow multiple readers on the stream, but honour the read offsets:
queue "future reads", and reply to them only when all the data up to
there has been read.

to use this, a client schedules multiple reads concurrently (making
sure that each reads at a consistent offset).

the nice thing about this is that it's invisible to a naive reader,
and works just the same on static files too; it also works for writing.

ideally a client that uses this could dynamically adapt the number of
reader processes according to the data transfer rate, but i'm not
quite sure of the best way to go about this.