[Http-crcsync] Is the crcsync effort still alive?

[Sergey Burkov]

Hello all

I used crcsync in following configuration: http://www.oscommerce-ajax.com/crcproxy.png
I can't provide the benchmarks, but I can say that in certain cases it
really can save up to 99% of traffic with rarely changing documents. However browsing a regular
internet forum shows little benefit (about 10%) comparing to a simple
traffic compression. I was hoping for a commercial use but I found out
that it can't compete with monsters like onspeed.com.
A typical problem - an internet site may have different debugging
information in html comments like this:
<!-- this page has been generated in 0.7658 seconds -->
Such a line will force the whole block containing this line to be redownloaded. So extra
html normalization may be required, though it's definitely not
crcsync's job.
However there is a plus: crcsync-enabled proxy in conjuction with
an image downsampling proxy (ziproxy in my case) allows to contunue
the download of partially downloaded resampled images that
is impossible for software like onspeed.com and opera turbo.

Feature requests:
-crcsync client should be able to request the number of crc-blocks.
-crcsync server should have an option to send uncompressed literals.


GM> The emptiness of the archives of this list suggest that the crcsync
GM> effort has died. Is that fair to say? If not, what is the status?

GM> I am still interested in looking into this for Firefox but I haven't the
GM> bandwidth to code it myself so it would need a working Apache module and
GM> some current benchmarks demonstrating benefit before I can persuade
GM> someone else to do it...

GM> Gerv
GM> _______________________________________________
GM> Http-crcsync mailing list
GM> Http-crcsync at lists.laptop.org
GM> http://lists.laptop.org/listinfo/http-crcsync



-- 
Best regards,
 Sergey                          mailto:fuzzoid at gmail.com