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
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <moon@justmoon.de>) id 1S3z9b-0003ws-My
for bitcoin-development@lists.sourceforge.net;
Sun, 04 Mar 2012 00:18:23 +0000
X-ACL-Warn:
Received: from sulfur.webpack.hosteurope.de ([217.115.142.104])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1S3z9Z-0007UD-Qf for bitcoin-development@lists.sourceforge.net;
Sun, 04 Mar 2012 00:18:23 +0000
Received: from 84-73-121-121.dclient.hispeed.ch ([84.73.121.121]
helo=[192.168.0.21]); authenticated
by sulfur.webpack.hosteurope.de running ExIM with esmtpsa
(TLSv1:AES256-SHA:256)
id 1S3z9T-0006eE-I2; Sun, 04 Mar 2012 01:18:15 +0100
Message-ID: <4F52B4C1.60604@justmoon.de>
Date: Sun, 04 Mar 2012 01:18:09 +0100
From: Stefan Thomas <moon@justmoon.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <201202281706.22650.luke@dashjr.org> <4F52294C.8080409@justmoon.de>
<201203031000.28760.luke@dashjr.org>
<345337E5-9645-40B7-9A77-F65DD1694CEA@mac.com>
In-Reply-To: <345337E5-9645-40B7-9A77-F65DD1694CEA@mac.com>
Content-Type: multipart/alternative;
boundary="------------050907030707050004040903"
X-bounce-key: webpack.hosteurope.de;moon@justmoon.de;1330820301;a47a7206;
X-Spam-Score: 0.8 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
-0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1S3z9Z-0007UD-Qf
Subject: Re: [Bitcoin-development] getmemorypool BIP process
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: Sun, 04 Mar 2012 00:18:23 -0000
This is a multi-part message in MIME format.
--------------050907030707050004040903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
> Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S->C json-rpc, what (javascript) library do you use for this?
As for an explicitly standard way, there is none. The JSON-RPC 1.0 spec
<http://json-rpc.org/wiki/specification> says "The specifications do not
require a certain transport protocol. The use of TCP/IP socket streams
is encouraged. The serialized request and response objects are sent to
the peers through the byte streams. " The JSON-RPC 2.0 spec
<http://jsonrpc.org/specification> goes out of its way to say "It is
transport agnostic in that the concepts can be used within the same
process, over sockets, over http, or in many various message passing
environments."
The de-facto standard for bidirectional JSON-RPC is plain TCP sockets.
BitcoinJS currently implements this - we detect whether an incoming
connection is HTTP or raw JSON-RPC based on the first character. (HTTP
must start with an uppercase letter, raw JSON-RPC must start with an
opening curly bracket.)
There are two things to watch out for with JSON-RPC over plain TCP:
1. Plain TCP sockets (unlike HTTP) have no standardized authentication
mechanism, so I added an extra RPC call auth("username", "password").
2. The TCP packets may or may not correspond to JSON-RPC messages. You
can either use a streaming JSON parser (yajl in ANSI C, Jackson in Java,
etc.), or you can just count (non-string-literal) curly braces to detect
when a complete message has arrived.
Many JSON-RPC libraries come with TCP socket support out of the box:
http://json-rpc.org/wiki/implementations
We're planning to add more features to our JSON-RPC API in the future,
such as:
- JSON-RPC over TLS sockets
- Challenge-response authentication
- TLS client handshake (certificate authentication)
As for HTTP Keep-Alive: It works, but I don't think it's very widely
supported among client libraries and HTTP isn't really made for this
type of thing, so my gut instinct would be to avoid it. That said, it
doesn't hurt to offer the option.
On 3/3/2012 6:08 PM, Michael Grønager wrote:
>> HTTP and JSON-RPC are a client-server model; there is no way for the server to
>> make calls to the client. It's not practical to expect clients to run their
>> own JSON-RPC server - many cannot listen on WAN ports at all.
> Well, I think what Stefan had in mind was http keep-alive combined with an event system. So similar to the way a web chat application work, just for json-rpc. BitcoinJS already uses this for realtime updating a webwallet. Libcoin is also prepared for this with a quite advanced, non-blocking, http server so I second Stefan that an update function could indeed be of relevance.
>
> Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S->C json-rpc, what (javascript) library do you use for this?
>
> Cheers,
>
> Michael
>
>
>> ------------------------------------------------------------------------------
>> Virtualization& Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Virtualization& Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--------------050907030707050004040903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote type="cite">
<pre wrap="">Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S->C json-rpc, what (javascript) library do you use for this?</pre>
</blockquote>
<br>
As for an explicitly standard way, there is none. The <a
href="http://json-rpc.org/wiki/specification">JSON-RPC 1.0 spec</a>
says "The specifications do not require a certain transport
protocol. The use of TCP/IP socket streams is encouraged. The
serialized request and response objects are sent to the peers
through the byte streams. " The <a
href="http://jsonrpc.org/specification">JSON-RPC 2.0 spec</a> goes
out of its way to say "It is transport agnostic in that the concepts
can be used within the same process, over sockets, over http, or in
many various message passing environments."<br>
<br>
The de-facto standard for bidirectional JSON-RPC is plain TCP
sockets. BitcoinJS currently implements this - we detect whether an
incoming connection is HTTP or raw JSON-RPC based on the first
character. (HTTP must start with an uppercase letter, raw JSON-RPC
must start with an opening curly bracket.)<br>
<br>
There are two things to watch out for with JSON-RPC over plain TCP:<br>
<br>
1. Plain TCP sockets (unlike HTTP) have no standardized
authentication mechanism, so I added an extra RPC call <tt>auth("username",
"password")</tt>.<br>
<br>
2. The TCP packets may or may not correspond to JSON-RPC messages.
You can either use a streaming JSON parser (yajl in ANSI C, Jackson
in Java, etc.), or you can just count (non-string-literal) curly
braces to detect when a complete message has arrived.<br>
<br>
Many JSON-RPC libraries come with TCP socket support out of the box:
<a class="moz-txt-link-freetext" href="http://json-rpc.org/wiki/implementations">http://json-rpc.org/wiki/implementations</a><br>
<br>
We're planning to add more features to our JSON-RPC API in the
future, such as:<br>
<br>
- JSON-RPC over TLS sockets<br>
- Challenge-response authentication<br>
- TLS client handshake (certificate authentication)<br>
<br>
As for HTTP Keep-Alive: It works, but I don't think it's very widely
supported among client libraries and HTTP isn't really made for this
type of thing, so my gut instinct would be to avoid it. That said,
it doesn't hurt to offer the option.<br>
<br>
On 3/3/2012 6:08 PM, Michael Grønager wrote:
<blockquote cite="mid:345337E5-9645-40B7-9A77-F65DD1694CEA@mac.com"
type="cite">
<blockquote type="cite">
<pre wrap="">
HTTP and JSON-RPC are a client-server model; there is no way for the server to
make calls to the client. It's not practical to expect clients to run their
own JSON-RPC server - many cannot listen on WAN ports at all.
</pre>
</blockquote>
<pre wrap="">
Well, I think what Stefan had in mind was http keep-alive combined with an event system. So similar to the way a web chat application work, just for json-rpc. BitcoinJS already uses this for realtime updating a webwallet. Libcoin is also prepared for this with a quite advanced, non-blocking, http server so I second Stefan that an update function could indeed be of relevance.
Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S->C json-rpc, what (javascript) library do you use for this?
Cheers,
Michael
</pre>
<blockquote type="cite">
<pre wrap="">
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
<a class="moz-txt-link-freetext" href="http://www.accelacomm.com/jaw/sfnl/114/51521223/">http://www.accelacomm.com/jaw/sfnl/114/51521223/</a>
_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<pre wrap="">
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
<a class="moz-txt-link-freetext" href="http://www.accelacomm.com/jaw/sfnl/114/51521223/">http://www.accelacomm.com/jaw/sfnl/114/51521223/</a>
_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------050907030707050004040903--
|
