On Thu, Apr 12, 2012 at 7:24 PM, Amir Taaki wrote: > Jeff elaborated the problems very well, but I just want to add this: > > Your change is essentially relying (trusting) the server to track a piece > of information (your state). No, it is more about distinguishing between replies (multiple asynchroneous request) and spontaneous notifications of the other peer. Every state would still be tracked locally on the client side. I don't understand why you say my proposal would make the protocol more stateful. I think it doesn't. Each reply is only the result of the current request only, and there is no new session information. As you see in my implementation, there is not even a new variable. Request/reply id is a very robust pattern that is compatible with stateless protocols. 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.