On Thu, Nov 6, 2008 at 9:47 AM, Mark Mielke <mark_at_mark.mielke.cc> wrote:
>...
> Not necessarily disagreeing - but another example I thought of:
>
> TCP/IP is stream-based, presented a serial stream of characters. In the case
> of an unreliable link, if a set of 64 Kbytes of packets are received, but
> the first 1K is corrupt or lost, we might have to wait for TCP/IP to signal
> a retry and wait for the missing 1K before the whole 64 Kbyte can be read by
> the server. This "wait" time will take the form of the pipe being idle at
> one or both sides for a measurable period of time (something a bit more than
> the round-trip latency of the connection). If two streams are running in
> parallel, the chance of both streams being interrupted at the same instant
> are lower.
Exactly, along with your previous email about the client or server
pausing their network operation in order to perform some activity. In
these scenarios, the pipe is stopped, but we will have *others* that
can continue doing work.
Having the client perform multiple GET operations on a checkout/update
is important for cacheability, but will be *very* important with the
new working copy. It is entirely possible that svn will find a copy of
a file on your system already, so it is NOT going to want the server
to unilaterally send the file down in a big glom of an update report
response.
Multiple PUTs may be more arguable, but if we're pipelining them, then
it doesn't really matter whether we do N PUTs or one mother glom POST.
As this thread has further expounded on... parallel PUTs are
definitely arguable, and so the answer is "don't argue about it. just
stick to serial PUTs for now".
More on cacheability in another note.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-06 19:33:06 CET