1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sirk390@gmail.com>) id 1SIR1g-0000uS-5a
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Apr 2012 20:53:56 +0000
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;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SIR1f-0002kn-HJ
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Apr 2012 20:53:56 +0000
Received: by obbuo13 with SMTP id uo13so4297988obb.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Apr 2012 13:53:50 -0700 (PDT)
Received: by 10.182.51.73 with SMTP id i9mr5171355obo.17.1334264029907; Thu,
12 Apr 2012 13:53:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.13.103 with HTTP; Thu, 12 Apr 2012 13:53:28 -0700 (PDT)
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
X-Spam-Score: -0.3 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(sirk390[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (sirk390[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1SIR1f-0002kn-HJ
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: sirk390@gmail.com
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 20:53:56 -0000
--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"><<a href=3D"mailto:zgenjix@yahoo.com" target=3D"_blank">zg=
enjix@yahoo.com</a>></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'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'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'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>
--f46d044470db8a0b5604bd818d05--
|
