📅 Original date posted:2012-03-03
📝 Original message:> 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120304/72c6808b/attachment.html>;
Stefan Thomas [ARCHIVE] /
npub1f8…ap20e
2023-06-07 03:11:56
in reply to nevent1q…6urp
Author Public Key
npub1f8c8h5evqyy29yp6p7jelyzw6vfwp6jz05exn66l4ygwkj57ytzqmap20ePublished at
2023-06-07 03:11:56Event JSON
{
"id": "acc5155efa93da319706e5fa18bde5a15153ef6c0541d9d07d62856e2d23fa59",
"pubkey": "49f07bd32c0108a2903a0fa59f904ed312e0ea427d3269eb5fa910eb4a9e22c4",
"created_at": 1686107516,
"kind": 1,
"tags": [
[
"e",
"3c851c8f17df1dd68608e4374d6cde0ed02a6a2268be0433e6610590ab1017ab",
"",
"root"
],
[
"e",
"5c7fcd69965962abe330aeb0ceed5acca80b86564309036726e56d3624bdafc8",
"",
"reply"
],
[
"p",
"a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f"
]
],
"content": "📅 Original date posted:2012-03-03\n📝 Original message:\u003e Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S-\u003eC json-rpc, what (javascript) library do you use for this?\n\nAs for an explicitly standard way, there is none. The JSON-RPC 1.0 spec \n\u003chttp://json-rpc.org/wiki/specification\u003e says \"The specifications do not \nrequire a certain transport protocol. The use of TCP/IP socket streams \nis encouraged. The serialized request and response objects are sent to \nthe peers through the byte streams. \" The JSON-RPC 2.0 spec \n\u003chttp://jsonrpc.org/specification\u003e goes out of its way to say \"It is \ntransport agnostic in that the concepts can be used within the same \nprocess, over sockets, over http, or in many various message passing \nenvironments.\"\n\nThe de-facto standard for bidirectional JSON-RPC is plain TCP sockets. \nBitcoinJS currently implements this - we detect whether an incoming \nconnection is HTTP or raw JSON-RPC based on the first character. (HTTP \nmust start with an uppercase letter, raw JSON-RPC must start with an \nopening curly bracket.)\n\nThere are two things to watch out for with JSON-RPC over plain TCP:\n\n1. Plain TCP sockets (unlike HTTP) have no standardized authentication \nmechanism, so I added an extra RPC call auth(\"username\", \"password\").\n\n2. The TCP packets may or may not correspond to JSON-RPC messages. You \ncan either use a streaming JSON parser (yajl in ANSI C, Jackson in Java, \netc.), or you can just count (non-string-literal) curly braces to detect \nwhen a complete message has arrived.\n\nMany JSON-RPC libraries come with TCP socket support out of the box: \nhttp://json-rpc.org/wiki/implementations\n\nWe're planning to add more features to our JSON-RPC API in the future, \nsuch as:\n\n- JSON-RPC over TLS sockets\n- Challenge-response authentication\n- TLS client handshake (certificate authentication)\n\nAs for HTTP Keep-Alive: It works, but I don't think it's very widely \nsupported among client libraries and HTTP isn't really made for this \ntype of thing, so my gut instinct would be to avoid it. That said, it \ndoesn't hurt to offer the option.\n\nOn 3/3/2012 6:08 PM, Michael Grønager wrote:\n\u003e\u003e HTTP and JSON-RPC are a client-server model; there is no way for the server to\n\u003e\u003e make calls to the client. It's not practical to expect clients to run their\n\u003e\u003e own JSON-RPC server - many cannot listen on WAN ports at all.\n\u003e 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.\n\u003e\n\u003e Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S-\u003eC json-rpc, what (javascript) library do you use for this?\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Michael\n\u003e\n\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Virtualization\u0026 Cloud Management Using Capacity Planning\n\u003e\u003e Cloud computing makes use of virtualization - but cloud computing\n\u003e\u003e also focuses on allowing computing to be delivered as a service.\n\u003e\u003e http://www.accelacomm.com/jaw/sfnl/114/51521223/\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Virtualization\u0026 Cloud Management Using Capacity Planning\n\u003e Cloud computing makes use of virtualization - but cloud computing\n\u003e also focuses on allowing computing to be delivered as a service.\n\u003e http://www.accelacomm.com/jaw/sfnl/114/51521223/\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120304/72c6808b/attachment.html\u003e",
"sig": "7da156733f40e8475ac06b92214baa1bbe6665aef89de8d52fb741330bd1debaaa5cffc5afc61edeb1eaf4665f6f3ae318abd59f77b27690e4d05e10af2a58e6"
}