In cases where multiple clients might map to the same fid you can also
freeze in a buffer file contents when the offset if zero, and serve from there
for further reads. Using 9p (and no cache in the client) means that you can use
the fid to mux the clients, and assign also a buffer per client, and
On Fri, Aug 10, 2007 at 08:32:18AM -0400, John Marshall wrote:
Although I was not immediately convinced that a versioning approach was
all that useful, I can now see that it roughly matches what I've always
done for servicing web requests for dynamically generated data: each
connection keeps a ve
matt wrote:
The coder for the file system makes the choice whether to keep a
snapshot of the data to be read per FID, this way the FID reader will
always get the file they asked for, which, after the first read, isn't
necessarily the current version or to just return whatever each Tread
asks f
And just to elucidate further one frees the data on a clunk.
It could be the source of a DoS if your 9p is public facing.
why not just tie the fid to a "file" version. then it would be easy
to handle offsets.
that's effectively what i do in similar cases. so does ndb/cs, amongst others.
> why not just tie the fid to a "file" version. then it would be easy
> to handle offsets.
that's effectively what i do in similar cases. so does ndb/cs, amongst others.
The coder for the file system makes the choice whether to keep a
snapshot of the data to be read per FID, this way the FID reader will
always get the file they asked for, which, after the first read, isn't
necessarily the current version or to just return whatever each Tread
asks for regardless
why not just tie the fid to a "file" version. then it would be easy
to handle offsets.
- erik
On Thu Aug 9 21:47:02 EDT 2007, [EMAIL PROTECTED] wrote:
> Hi,
>
> I am trying to understand the general practice, under
> Plan 9, for synthetic filesystems for serving up a "file"
> which:
> 1) retur
Hi,
I am trying to understand the general practice, under
Plan 9, for synthetic filesystems for serving up a "file"
which:
1) returns data that changes (quickly), and
2) returns data whose size is larger than the message
size agreed upon at *version interchange.
Practically, what I am wonderi
