> I know, I think I was not clear, sorry.
>
> The point is that, referring to the
> Tinval-Rinval-Tinval-...
> sequence, a server could afford to consider its Rinval acknowledged
> if the client happens not to respond (by issuing another Tinval)
> within 5 seconds.
> That would "freeze" clients for at most 5 seconds when a client fails
> to respond,
> but that should not happen often, and it would not make other clients slow.
>
> Also, regarding
>> the irony is, the higher the latency, the greater the cost of syncronization.
>
> if we consider that this would happen only for rw files, and that rd files
> would
> be considered as leased up to the next Rinval mentioning them, the cost would
> not probably be too high. But I won´t actually know before
> implementing and trying it.
There's a funny obsession in this discussion with optimal performance
in the least common scenarios.
Let me reiterate:
1. 90% (a symbolic number) of files are not shared
2. Of the 10% remaining, 90% of files are read-shared
3. Of the 1 % remaining, 90% of clients are well-behaved
4. In the 0.1% remaining, only the first request in a series
of requests issued by a badly behaving client will result in
making the server wait for the lease timeout (in all subsequent cases,
the server just won't give that client a lease or an extremely short
one)
5. That leaves 0.01%of files. Optimize away, guys.
Sape
