Published on: 2012-03-04T17:49:00+00:00
Geir Harald Hansen proposed a solution to the race condition in long polling implemented in pools. He suggested adding "longpollid" in long poll responses and for the client to include the last seen longpollid in future requests. This would allow the server to check if the client has missed any block changes. Additionally, Hansen recommended including the "height" value in the getmemorypool response so that miners can include the correct height in the coinbase. However, adding parameters to getmemorypool itself breaks compatibility with bitcoind 0.5, and using HTTP headers makes it HTTP-specific again. It was suggested that some features should be optional for clients to implement, but this requires a way for clients to communicate their capabilities to the server. Lastly, it was mentioned that "noncerange" is of limited use and could result in getting the endianness wrong.In a discussion between Luke-Jr and Gavin Andresen, the limitations of using JSON-RPC for server to client calls were highlighted. Gavin pointed out that JSON-RPC and HTTP are client-server models that don't allow the server to make calls to the client, making it impractical for clients to run their own JSON-RPC server. However, Luke-Jr updated the draft to include long polling and remove assumptions of using HTTP for transport. The context also provides a link to a page about virtualization and cloud management using capacity planning, which explains how cloud computing uses virtualization to deliver computing as a service. There is also information about the Bitcoin-development mailing list with a link to sign up for it.The context mentions that there is no explicit standard way to do S->C JSON-RPC. The JSON-RPC 1.0 spec doesn't require a specific transport protocol, while the JSON-RPC 2.0 spec is transport agnostic. Plain TCP sockets are commonly used for bidirectional JSON-RPC, but they lack a standardized authentication mechanism. The use of HTTP Keep-Alive with an event system, similar to web chat applications, was suggested as a solution. It was noted that HTTP Keep-Alive works but is not widely supported among client libraries, and HTTP itself isn't designed for this type of usage. Adding challenge-response authentication and TLS support to the JSON-RPC API in the future was also mentioned.A proposal called "getmemorypool" has been submitted as part of the Bitcoin Improvement Proposal (BIP) draft by Luke-Jr. The proposal aims to improve the memory pool process for miners by providing details about unconfirmed transactions. This would help miners select transactions more efficiently for inclusion in the next block. The proposal suggests adding additional values like "longpollid" and "height" to the getmemorypool response. Geir Harald Hansen provided comments on the proposal, suggesting clarifications and making certain features optional for clients to implement. The context also mentions Stefan Thomas initiating a discussion about the use of a polling model in BIP and the interest in a "push" API using JSON-RPC over TCP.Overall, the proposed changes aim to address issues with long polling in pools, improve communication between servers and clients using JSON-RPC, and enhance the memory pool process for miners. These developments have the potential to make the Bitcoin network more efficient and secure.
Updated on: 2023-08-01T03:21:29.402892+00:00