Re: Link latency and ra_svn/ra_dav performance

On Wed, 2003-10-22 at 19:43, Tobias Ringström wrote:
> All of these suggestions are protocol changes

I can swing the protocol changes with a capability string.

> I don't think it's *too* hard to implement overlapping requests,
> as in the following example.

> 1. send file 1
> 2. send file 2
> 3. read status (for file 1)

I have several concerns here:

  1. Is it too confusing, from an API perspective, to have a
close_file() return an error for a *different* file? I'm okay with
deferring an file opreation error until close_edit() or close_dir(),
because the file operation is contained within the directory or edit
operation. But I'm not sure about this sibling relationship.

  2. Is the implementation too ugly and error-prone? It requires
maintaining state in the edit baton and acting on it for every editor
operation which can follow a close_file() or close_directory()
operation.

  3. Are we theoretically at risk of TCP deadlock? The server could
block trying to write a status while we block trying to write a file.
This seems unlikely given how little data the server is writing, but
it's still not correct use of TCP. For this reason, SMTP pipelining
requires that clients use non-blocking writes, so that they can read
some replies from the server and break the deadlock.

  4. How often is a send window of just two files enough to eliminate
the latency problem? It might be enough in almost all cases, but that
seems like too much reliance on intuition.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 23 03:20:10 2003