Setting the "LowPower" mode on the main DownloadManager class will
cause it to halt all network activity and jobs will die.
You can revive it by changing it to NormalPower and optionally calling
the start() method to restart all jobs.
This is an abstract class that the application using this library needs
to subclass. Ownership and lifetime don't change, it still lies with the
app using the library and they still need to add and remove it from the
connectionManager, but this makes it much more stable for multi-
threading environments and avoids issues on misuse.
When we didn't personally verify the services, don't judge the IP based
on them and connect anyway.
In addition to not trusting the services we receive from the net, be
more careful with the usage of the 'lastConnected' field.
Notice that we don't actually use the result of that variable in the end
if the everConnected is likewise incorrect.
Last year we started wrapping the Peer object in a shared pointer,
which is used now in the managers.
This continues the idea by making the PrivacySegment use smart
pointers too and the P2PNetInterface is changed to do the same
for downstream applications.
The PeerAddressDB keeps a score for each IP/port we have about how
useful that peer is.
This change re-visits the way we use the DB where we now are more fluid
in our approach to scores. We no longer simply forever-ban a peer after
it made a mistake once.
This rewrites the select-a-peer algo to take timing into account,
preferring a peer that we connected to recently while putting a higher
score on a peer that failed a long time ago so if we start running out
of good peers we start on the not-so-great-but-maybe-improved first.
Good behavior is likewise rewarded so a peer can become higher prio
again, but generally a new IP still gets preferred. Again, the balance
is to keep not-so-great options in the running.
When the SyncChainAction was written, various interactions we do
today in the ConnectionManager did not happen yet. Features in
Peer didn't exist yet.
This updates the SyncChainAction to take those items into account
and be more responsive and conclue we are 'up to date' faster,
while also leaving behind a better state.
To enable this means the buildsystem will build all the applications
as well as the libraries.
Applications are 'hub' / 'txVulcano' / 'indexer' etc.
Default this one is turned off.
When we receive a known message (currently just avahello) we now
intantly ban and disconnect the peer, no need to
test compliance when they openly greet us saying they are not following
the same chain.
Now we have 3 more logically divided interfaces for the listener
pattern (callbacks).
A P2PNetInterface for peers maintainance.
A DataListenerInterface for the sections getting new data.
And last the new HeaderSyncInterface about the state of the
header-chain (application wide).
Version.h held mostly stuff for protocol.h, which is a hub-specific file.
The only thing that we actually use is the PROTOCOL_VERSION in our code
and as such that one moved to the interfaces dir.
A peer that is behind is marked as "on a different chain", which is
ultimately correct, but the response to punish or ban them is too much.
We could very well reconnect later when the situation is resolved.
So, detect when a peer is simply behind and respond by disconnecting
without punishment.
On connect, we should ask for a HEADERS overview from the remote peer,
even if we aren't fully at the tip yet.
Also remove some old lookup no longer used.
Sometimes a node would not be online for a while and we'd incorrectly
ban them for a long time when we just need to mark them as not-
reachable-right-now.
Instead of assigning a privacy segment at connect, wait until we have
determined if this peer is on the same chain as us before we allocate a
peer slot.
This also helps us limit the amount of peers we send our bloom filter to.
This is done in several steps:
1. Separate my height from the remote peer heights.
Instead of assuming we have one height, recognize that a peer may
not be at the tip at the same time we are. We monitor headers/invs
to update the 'peerHeight' variable.
2. Ask for merkle blocks from a peer to the maximum height of that
peer (but not later than what we validated to be true).
This avoids us asking past the remotes tip which they didn't like.
3. Redo the SyncSPVAction to use all this and make it much more
reliable in finding peers to download from and getting all the
changes as fast as possible.
To send out transactions in the p2p net is quite a lot of work,
you need to find multiple peers to send the transaction to. First
you send an INV, then you respond to a getData to actually send
the transaction and last you wait for 'reject' messages that may
indicate that there is something wrong with the transaction.
This introduces the BroadcastTxData class that wraps a transaction
and gets callbacks for sending and for rejects, abstracting away
all the complexity for the user.
tomFlowee
TomZ