[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Link latency and ra_svn/ra_dav performance

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-10-23 03:19:20 CEST

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()

  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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.