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

Re: [Sketch] Don't checksum reliable transmissions

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Mon, 03 May 2010 23:05:48 +0200

Blair Zajac wrote:
> On 5/2/10 8:56 AM, Philipp Marek wrote:
>> Hello Stefan!
>>
>>> The idea is the following: ra_local (and possibly others)
>>> are "reliable" in that they won't corrupt transmission.
>>> For now, this implies that we don't need to checksum
>>> the data again. There might be more shortcuts that
>>> can be taken in the future.
>> ...
>>> With all other patches applied, this saves 15% runtime
>>> in 'svn export file://'. However, rev'ing svn_delta_editor_t
>>> seems only be feasible in context of 'editor v2'.
>> I understand your point, and 15% sound very interesting.
>>
>> But I'd like to note that even for local operations it's a nice
>> feature to avoid data
>> corruption via software bugs (off-by-one and similar), and over LAN
>> it's nice to have,
>> too (eg. because of bugs in switches and routers, see eg.
>> http://www.cs.pitt.edu/~kyoungsoo/cs2520/papers/CRC_TCP_Checksum.pdf).
>>
>> As the WAN (Internet) uses the same protocols as a LAN (TCP, IP)
>> following that argument
>> would mean that the checksum is informational only, and doesn't need
>> to be checked.
>>
>>
>> So I'd propose that this would be configurable for the paranoid
>> people (like me, maybe ;-).
>
> Given the size of the patch, reving of the API and that I like the
> checksum to always be done, I would just have svn always perform the
> checksums.
>
But you know that today ra_local does NOT checksum
for certain operations, at least for single file gets / exports.
However, I can see the point in making it a client-side option -
maybe on a per-server basis just like everything else in
the 'servers' config file.

-- Stefan^2.
Received on 2010-05-03 23:33:05 CEST

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.