On Wed, Oct 22, 2003 at 09:19:20PM -0400, Greg Hudson wrote:
> 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.
Dunno.
>
> 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.
Tricky, yes.
>
> 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.
Yes, unless we do something like have the client buffer any sends
that would have blocked, so that it can continue executing until it
gets to a recv state. This could potentially require a very large
buffer.
>
> 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.
>
That's probably easier to measure than predict. :-)
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 23 04:58:51 2003