On Thu, Apr 12, 2012 at 7:24 PM, Amir Taaki <zgen...@yahoo.com> 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.
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
