The code, comments, and documentation were saying "MiB" (mebibyte, e.g.
2^20) in places when really they meant "MB" (= 1 million bytes).
This inconsistency has been fixed in all code, documentation, and
comments. I had to rename some JSON keys from `getinfo` but hopefully
this won't break anyone's scripts or code that depend on this esoteric
admin RPC call.
Also in this commit: off-by-1 inaccuracy in computing the LRU num2hash
and height2hashes cache entry sizes. TxHash actually takes 33 bytes of
memory, not 32 per data item (QByteArray always appends a nul byte).
Now it's possible to start Fulcrum with ws://, wss:// support. This
commit contains various changes:
- Added config vars: ws, wss, public_ws_port, public_wss_port,
tor_ws_port, tor_wss_port
- Added CLI options -w/--ws and -W/--wss
- Modified FulcrumAdmin script to show WS & WSS client types
- Modified server name and logger to show WS/WSS clients properly in the
log.
- Updated the man page and the inline comments/documentation in the
example configs.
- Various nits and fixups in the code.
- Fixed a typo or two in documentation.
See 'FulcrumAdmin -h bitcoind_throttle' for how to use this command.
Also got rid of 'setmaxbuffer' and made 'maxbuffer' both query and
set, depending on if it has args or not.
Also in this commit: Set the default max_buffer back to 4000000.
Now we have the ability to set the max_buffer at runtime.
This is accomplished by two new FulcrumAdmin commands: `setmaxbuffer` for
setting and `maxbuffer` for reading.
The max_buffer will, in future commits, be more aggressively enforced
and clients exceeding it for a long enough period of time will be
kicked.
Raw seconds are no longer displayed.. instead the value is tranformed to
minutes, hours, days, months, etc.
Also added an additional column to the clients display, which is the
'Elapsed' column which shows how long a particular client has been
connected.
The rmpeer command is like a weak banpeer. It just immediately
disconnects said peer(s) from the server and/or deletes their entries
from the internal peers table. However, unlike banpeer, the peer is not
banned and thus it may come back at any time in the future if our other
peers tell us about it.
rmpeer's primary usecase is intended for admins to remove defunct seed
peers from the peer list, or to undo a previous badly-inputted 'addpeer'
command.
Also in this commit: It occurred to me that our policy of purging
"Failed" peers after 24 hours of being failed has an edge case that is
not good: Namely the running server may lose internet connectivity for
24 hours without the operator noticing or restarting it. When the
server finally has connectivity again -- it will have purged all its
failed peers.. including the seed peers. This is not a good situation,
since now the server has no "lifeline" to the outside world and cannot
announce itself to other servers.
To mitigate this, we simply never purge the seed peers (the ones in
servers.json) from our tables and will retry them indefinitely forever.
This has very little downside, and mitigates the pathological case where
the outside world goes away and comes back again after 24 hours.
Basically enqueues the peer immediately if not already in the peer list.
If this is an "update" to an existing failed peer, it will update the
port info and the app will try again in ~10 mins.
If the peer already exists and is already valid and connected, then the
addpeer request is silently ignored (even if the ports specified on CLI
differ).
Coming soon: 'rmpeer' to explicitly delete peers (but not ban them)
Refactored the code a bit. Banning peeers is hostname-suffix-based so
some.server.com is the same as *.some.server.com internally. This works
well in practice if a little confusing for users.
The admin script has been updated slightly too.
Also this commit has some internal refactorings and nits.
These work by-IP only currently. Hostname banning is trickier (involves
DNS lookups, etc) and may not be required for client banning.
IP banning doesn't affect peering yet. That will be added in a
subsequent commit.
Kick clients by ID or by IP address. Accepts multiple arguments on the
command-line (may be a mixed IP address/ID). Because it accepts
multiple arguments, it's compatible with things like e.g. xargs on the
CLI.
