Philip Homburg <[email protected]> writes: > Just a random idea: turn the protocol upside down
You and Ben suggested basically the same thing, which definitely is an option. That does require hashing for every request on the server side, or keeping state of the hashes on the server side for performance reasons. But in the end, your signal to the client is about the same: yes it's changed, but it's too large (TC) and so you need to get more data. In the end I chose to put the decision burden on the client rather than the server, as the server in the end basically always has to say "yes come back to get more" or "you don't need more" and that response will always be the same independent of whether the client sends additional data or not (assuming the TC bit needs to be set). -- Wes Hardaker Google _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
