Jonathan S. Shapiro said:
> I'ld already got here, partly as a side effect of needing to deal with
> replicated servers. NFS has too many error cases, a couple of which have
> bitten the EROS tree over the years.
Agreed -- it's a nightmare! esp. with time synchronisation and long-distance use. And if you throw e.g. Windoze machines into the mix, then it really gets hairy...
> A major question is to what degree should the server interface support
> asynchrony? For example, when the client is fetching a bunch of objects from
> the server, should it be sending requests and receiving replies
> simultaneously?
>
> I think the answer is probably yes, though I'm not convinced that this is
> true over a modem. It used to be the case that modems tried to optimize
> upstream vs. downstream bandwidth, and the heuristics were pretty bad. How
> does streaming interact with this?
I don't think full asynchrony would really be required given the extra complexity it'd introduce, but it'd be nice if the client could request a batch of info (file contents or deltas etc.) at once, to cut down the effects of latency.
If batch-requests were supported, an update of a stack of files/deltas would be quite efficient as there'd be less packet round trips required to satisfy it. ie.
C S --------> file 1 please <-------- --------> file 2 <-------- --------> file 3 <--------
would become
C S --------> file 1, file 2, file 3 please <-------- <-------- <--------
(note that, after file/delta 1, the transfers of files/deltas 2 and 3 don't need to wait for any kind of acknowledgement from C before beginning.)
What does rsync do? It seems to have a very effective sync-over-a-socket mechanism.
--j.
--
Justin Mason Work: http://www.netnoteinc.com/ <jm@netnoteinc.com>
Personal: http://jmason.org/ <jm@jmason.org>
"It's true that some sharks get cancer. I said this in my book."
-- William Lane, author of _Sharks Don't Get Cancer_