The complete hash scenario (as long as we are hashing the trailing block then we dont need the strong hash) is not relevant in the two proxy case that we are working on at the moment, but could be used by http-sync aware servers who know how their own content has changed. For a news site that has just updated a story, or any site which embeds rotating ads in their content, it would allow them to return on the changes at a byte resolution rather than at a block resolution.<br>
<br>The classic approach provides a means to determine whether a new page needs to be fetched, I was hoping to provide a means that an update can be sent as the response instead of requiring a full page fetch. This does require the server to know exactly which page you have locally though. Actually thinking about it sending the etag of the cached page would actually be pretty good for this, as it is up to the server to decide what goes into that field so they could use it quiet effeciently.<br>
<br>Toby<br><br><div class="gmail_quote">2009/4/6 Alex Wulms <span dir="ltr"><<a href="mailto:alex.wulms@scarlet.be">alex.wulms@scarlet.be</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Op zondag 5 april 2009, schreef Rusty Russell:<br>
<div class="im">> On Sunday 05 April 2009 07:33:06 Alex Wulms wrote:<br>
><br>
</div><div class="im">> I think Toby's draft, which suggested just leaving the trailing block as<br>
> a literal, is an interesting possibility. Worst case, it's 19 bytes.<br>
</div>Actually, in worst case scenario it is (blocksize-1) = (pagesize/20 - 1).<br>
But that is not the main reason the code had to be adapted. Main reason is<br>
that the automatic tail detection in the previous version of crcsync library<br>
did give complications with keeping track of what was already written back to<br>
the client and what was still pending (especially when read_block returned<br>
a 'result==0' response), which had led to a subtle bug in crccache. That is<br>
the problem I wanted to get fixed, which is meanwhile done. The fact that the<br>
tailblock is now also encoded is just a nice added bonus of a problem<br>
investigation and it's associated bug fix :-)<br>
<div class="im"><br>
><br>
> I also think we should go to 60-bit csums (but needs new CRC algo).<br>
</div>I agree that that would indeed be better.<br>
<div class="im"><br>
><br>
> Finally, I think the strong hash sent in request in Toby's draft is not<br>
> useful as the block signature + size can be used for caching in exactly the<br>
> same way.<br>
</div>I was already wondering about the value of the strong hash in the request in<br>
Toby's draft.<br>
What kind of scenario could that be used for? Would the purpose be that the<br>
server caches complete pages? Can't that be handled with the<br>
classical 'last-modified/modified-since/304-not-modified' protocol? The<br>
purpose of crccache/crcsync is to cache the 'static' part of dynamic pages.<br>
So I do not directly see the added value to use a strong hash or a<br>
block-signature+size to detect 'unmodified' pages at the server level, when a<br>
simpler and faster protocol already exists.<br>
<br>
Kind regards,<br>
<font color="#888888">Alex<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>This email is intended for the addressee only and may contain privileged and/or confidential information<br>