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
132
133
134
135
136
137
138
139
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1SIa24-0006C6-9e
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Apr 2012 06:30:56 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.47 as permitted sender)
client-ip=209.85.160.47; envelope-from=laanwj@gmail.com;
helo=mail-pb0-f47.google.com;
Received: from mail-pb0-f47.google.com ([209.85.160.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SIa23-0007eI-KX
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Apr 2012 06:30:56 +0000
Received: by pbcum15 with SMTP id um15so3530346pbc.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Apr 2012 23:30:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.218.198 with SMTP id pi6mr2153436pbc.100.1334298649809;
Thu, 12 Apr 2012 23:30:49 -0700 (PDT)
Received: by 10.142.242.19 with HTTP; Thu, 12 Apr 2012 23:30:49 -0700 (PDT)
In-Reply-To: <CA+XhJbp8+ngso0esDAA415eoBVEZ3NGvuVY7G-hUU72K5wFstw@mail.gmail.com>
References: <CA+XhJbpNYUyPm2Ymcpg3grbfGnfERCsUJNJuByEJbJLsMMmMbQ@mail.gmail.com>
<CA+8xBpco-yPYB+cjoi_+srG2BkC2ZQBh-3HGNA5EaSB3FWNgog@mail.gmail.com>
<1334251458.43194.YahooMailNeo@web121005.mail.ne1.yahoo.com>
<CA+XhJbp8+ngso0esDAA415eoBVEZ3NGvuVY7G-hUU72K5wFstw@mail.gmail.com>
Date: Fri, 13 Apr 2012 08:30:49 +0200
Message-ID: <CA+s+GJD4PFh1Xh+goVi3iqmYYQ+2e-L8D6_Q5_JD5gUDn0PaRQ@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: sirk390@gmail.com
Content-Type: multipart/alternative; boundary=e89a8f503bea0bd3e404bd899dc1
X-Spam-Score: -0.6 (/)
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
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1SIa23-0007eI-KX
Cc: bitcoin-development@lists.sourceforge.net
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
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: Fri, 13 Apr 2012 06:30:56 -0000
--e89a8f503bea0bd3e404bd899dc1
Content-Type: text/plain; charset=UTF-8
>
>
> 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.
>
I also wondered this. My first thought was that it's basically the same as
the PING message, a nonce that is repeated immediately on reply. This makes
it easier to multiplex operations over a single channel. I'm not against
this basic idea, and it is easy to ignore for clients that don't want to
use it.
I think the state comes in here:
- inv sends back the requestid given in getblocks or a special value
in case of a notification.
- addr sends back the requestid given in getaddr or a special value
in case of a notification.
"*command1* sends back the requestid given in *command2*".
This requires keeping state on the connection between command1 and
command2. Arguably, this state already exists in the current protocol, but
I'd rather see it reduced than extended.
Also... Many of the described commands don't need this as they already have
a natural "nonce". For example, the id of the requested block header. If
this is passed in the reply, and the caller can correlate the request and
reply without a special nonce administration.
Wladimir
--e89a8f503bea0bd3e404bd899dc1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gma=
il_quote"><div><br></div><div>I don't understand why you say my proposa=
l would make the protocol more stateful<span style=3D"line-height:16px;colo=
r:rgb(51,51,51);font-size:13px;font-family:arial,helvetica,clean,sans-serif=
">. 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></blockquote><div><br><=
/div><div>I also wondered this. My first thought was that it's basicall=
y the same as the PING message, a nonce that is repeated immediately on rep=
ly. This makes it easier to multiplex operations over a single channel. I&#=
39;m not against this basic idea, and it is easy to ignore for clients that=
don't want to use it.</div>
<div><br></div><div>I think the state comes in here:</div><div><br></div><d=
iv><div style>=C2=A0 =C2=A0 =C2=A0 - inv sends back the=C2=A0requestid=C2=
=A0given=C2=A0in getblocks or a special value in case of a=C2=A0notificatio=
n.</div><div style>=C2=A0 =C2=A0 =C2=A0 - addr sends back the=C2=A0requesti=
d=C2=A0given=C2=A0in getaddr or a special value in case of a=C2=A0notificat=
ion.</div>
</div><div><br></div><div>"*command1* sends back the requestid given i=
n *command2*".</div><div><br></div><div>This requires keeping state on=
the connection between command1 and command2. Arguably, this state already=
exists in the current protocol, but I'd rather see it reduced than ext=
ended.</div>
<div><br></div><div>Also... Many of the described commands don't need t=
his as they already have a natural "nonce". For example, the id o=
f the requested block header. If this is passed in the reply, and the calle=
r can correlate the request and reply without a special nonce administratio=
n.</div>
<div><br></div><div>Wladimir</div><div><br></div></div>
--e89a8f503bea0bd3e404bd899dc1--
|
