Define errors (previously done in btcwallet and btcd's rpcserver) in
one place so they can just be called by name rather than generated in
code using btcjson.
Closes#5
Rather than having to keep the usage in sync with the supported commands,
simply include the usage as a field in the command handlers map and
dynamically generate the usage from there.
This commit modifies the command handler in btcctl to check the existence
of a display handler before issues an RPC command. This prevents a round
trip to the server if there is no display handler.
Also, fix a couple of comments while here.
This commit significantly reworks btcctl to use a map based approach to
command handling. This reduces the number of lines of code needed,
simplifies adding new commands, improves the error handling, and removes
several cases where unexpected data was not handled properly (it could
panic).
This commit also adds the ability to specify the optional parameter on
getrawtransaction.
Discussed with dhill@.
It was previously possible for the unprotected iteration of the mempool
orphans to lead to undefined results. This commit remedies that by
reworking the locking code a bit. It also embeds the mutex directly into
the mempool struct rather than having a separate field for it so the
syntax is a slightly cleaner.
Results from FetchTxByShaList must each be checked for a nil Err and a
non-nil Tx. Fix this issue in two places where these conditions were
not being checked.
The latest websockets code added a quit channel to the RPC server, but did
not initialize it. This commit corrects that so shutdown works properly
again.
If we don't hear from a peer for 5 minutes, we disconnect them. To keep
traffic flowing we send a ping every 2 minutes if we have not send any
other message that should get a reply.
This refactors the wallet notification code to reverse the order of
how notification contexts are stored. Before, watched addresses and
outpoints were used as keys, with a special reply channel as the
value. This channel was read from and replies were marshalled and
sent to the main wallet notification chan, but the goroutine handling
this marshalling never exited because the reply channel was never
closed (and couldn't have been, because there was no way to tell it
was handling notifications for any particular wallet).
Notification contexts are now primarily mapped by wallet notification
channels, and code to send the notifications send directly to the
wallet channel, with the previous goroutine reading the reply chan
properly closing.
The RPC code is also refactored with this change as well, to separate
it more from websocket code. Websocket JSON extensions are no longer
available to RPC clients.
While here, unbreak RPC. Previously, replies were never sent back.
This broke when I merged in my websocket code, as sends for the reply
channel in jsonRead blocked before a reader for the channel was
opened. A 3 liner could have fixed this, but doing a proper fix
(changing jsonRead so it did not use the reply channel as it is
unneeded for the standard RPC API) is preferred.
This change paves the way for running btcwallet on the same system without
having to change any settings. The well-known ports used by the
reference implementation (8332 mainnet, 18332 testnet) will be exposed by
the separate wallet process, which will in turn forward unknown requests
to btcd via websockets (on 8334/18334). This allows the wallet process to
ultimately provide a unified interface that exposes the same RPC-JSON API
as the reference implementation will maintaining wallet and chain
separation.
This commit modifies the main processing loop for orphan dependencies
(orphans that are processed due to their parents showing up) to use an
index based for loop over range. Since the Go range statement does not
reevaluate on every iteration, it was previously possible under certain
circumstances for the slice to be changed out from under the range
statement while processing the orphan blocks.
This commit adds the infrastructure needed to re-run the integrity tests
after calling the InvalidBlockCache, InvalidateTxCache, and
InvalidateCache functions. The tests intentially randomize the order the
invalidate functions are called in to increase the likelyhood of finding
in issues realted to ordering of the calls.
