<div class="gmail_quote">On Thu, Apr 12, 2012 at 7:24 PM, Amir Taaki <span dir="ltr"><<a href="mailto:zgenjix@yahoo.com" target="_blank">zgenjix@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jeff elaborated the problems very well, but I just want to add this:<br>
<br>
Your change is essentially relying (trusting) the server to track a piece of information (your state).</blockquote><div> </div><div>No, it is more about distinguishing between replies (multiple asynchroneous request) and spontaneous notifications of the other peer.</div>
<div>Every state would still be tracked locally on the client side.</div><div><br></div><div>I don't understand why you say my proposal would make the protocol more stateful<span style="background-color:rgb(255,255,255);color:rgb(51,51,51);font-family:arial,helvetica,clean,sans-serif;font-size:13px;line-height:16px">. I think it doesn't.</span></div>
<div>Each reply is only the result of the current request only, and there is no new session information.</div><div>As you see in my implementation, there is not even a new variable.</div><div><div>Request/reply id is a very robust pattern that is compatible with stateless protocols. </div>
</div><div><br></div><div>Indead, this change doesn't directly improve on peer that don't answer requests: it only enables to do so easily in a secondary step. This step can only be done when all peers on the network are running the modified code.</div>
<div><br></div><div><br></div></div><br>