I initially made the client block if the 100-element buffer was
exceeded. It turns out that this is inconvenient for simple uses of the
client which subscribe and perform calls on the same goroutine, e.g.
client, _ := rpc.Dial(...)
ch := make(chan int) // note: no buffer
sub, _ := client.EthSubscribe(ch, "something")
for event := range ch {
client.Call(...)
}
This innocent looking code will lock up if the server suddenly decides
to send 2000 notifications. In this case, the client's main loop won't
accept the call because it is trying to deliver a notification to ch.
The issue is kind of hard to explain in the docs and few people will
actually read them. Buffering is the simple option and works with close
to no overhead for subscribers that always listen.
If a batch request contained an invalid method, the server would reply
with a non-batch error response. Fix this by tracking an error for each
batch element.
The server delayed closing of connections for 3s when stopping. This was
supposed to allow for slow handlers, but it didn't really work. When
geth quits, it will just exit immediately after quitting the server.
Removing the timer makes testing easier because all connections will be
closed after Stop returns.
Context keys must have a unique type in order to prevent
any unintented clashes. The code used int(1) as key.
Fix it by implementing the pattern recommended by package context.
rpc: be less restrictive on the request id
rpc: improved documentation
console: upgrade web3.js to version 0.16.0
rpc: cache http connections
rpc: rename wsDomains parameter to wsOrigins
The debug package provides an RPC wrapper for glog settings and the
debugging facilities of the Go runtime. They can be triggered through
both command line flags and the IPC listener.
This removes the burden on a single object to take care of all
validation and state processing. Now instead the validation is done by
the `core.BlockValidator` (`types.Validator`) that takes care of both
header and uncle validation through the `ValidateBlock` method and state
validation through the `ValidateState` method. The state processing is
done by a new object `core.StateProcessor` (`types.Processor`) and
accepts a new state as input and uses that to process the given block's
transactions (and uncles for rewords) to calculate the state root for
the next block (P_n + 1).
SignTransaction creates a transaction but does submit it to the
network. SignTransaction returns a structure which includes the
transaction object details as well as the RLP encoded transaction that
could possibly be submitted by the SendRawTransaction method.