Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.175 as permitted sender)
	client-ip=209.85.214.175; envelope-from=sirk390@gmail.com;
	helo=mail-ob0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <1334251458.43194.YahooMailNeo@web121005.mail.ne1.yahoo.com>
References: <CA+XhJbpNYUyPm2Ymcpg3grbfGnfERCsUJNJuByEJbJLsMMmMbQ@mail.gmail.com>
	<CA+8xBpco-yPYB+cjoi_+srG2BkC2ZQBh-3HGNA5EaSB3FWNgog@mail.gmail.com>
	<1334251458.43194.YahooMailNeo@web121005.mail.ne1.yahoo.com>
From: Christian Bodt <sirk390@gmail.com>
Date: Thu, 12 Apr 2012 22:53:28 +0200
Message-ID: <CA+XhJbp8+ngso0esDAA415eoBVEZ3NGvuVY7G-hUU72K5wFstw@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=f46d044470db8a0b5604bd818d05
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
Precedence: list
Reply-To: sirk390@gmail.com

--f46d044470db8a0b5604bd818d05
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 12, 2012 at 7:24 PM, Amir Taaki <zgenjix@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.

--f46d044470db8a0b5604bd818d05
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Apr 12, 2012 at 7:24 PM, Amir Taaki <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:zgenjix@yahoo.com" target=3D"_blank">zg=
enjix@yahoo.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"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 o=
f information (your state).</blockquote><div>=C2=A0</div><div>No, it is mor=
e 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><d=
iv><br></div><div>I don&#39;t understand why you say my proposal would make=
 the protocol more stateful<span style=3D"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&#39;t.</span></div>

<div>Each reply is only =C2=A0the result of the current request=C2=A0only, =
and there is no new session information.</div><div>As you see in my impleme=
ntation, there is not even a new variable.</div><div><div>Request/reply id =
is a very=C2=A0robust pattern that is compatible with stateless protocols.=
=C2=A0</div>

</div><div><br></div><div>Indead, this change doesn&#39;t directly improve =
on peer that don&#39;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>

--f46d044470db8a0b5604bd818d05--