Connect to last connected peers, take efforts to connect to P2P network more quickly

[GoogleCodeExporter]

Currently, if peer discovery fails, no peers will be connected at all. Even if 
peer discovery succeeds, connecting to peers is delayed more than it should.

I propose BitCoinJ should keep a number of IPs/hosts last connected to and 
instantly connect to them until peer discovery succeeds. I would even go that 
far and trying connect to old peers in parallel to discovering new peers.

The goal should be to connect to the Bitcoin P2P network as quickly as 
possible. The longer it takes, the longer users have to wait until their 
transactions are sent, etc.

Original issue reported on code.google.com by andreas....@gmail.com on 3 Mar 2012 at 1:17

[GoogleCodeExporter]

Yeah, an overhaul of peer management should come at some point. Satoshis actual 
plan for peer connectivity was to rely on discovery only for initial bootstrap, 
and then use peers discovered via "addr" broadcasts after. His implementation 
is lacking in a few ways though (no pruning of old addresses), but the general 
idea is sound.

Original comment by hearn@google.com on 5 Mar 2012 at 8:55

[GoogleCodeExporter]

Last night, I had the idea that connecting to last connected peers could be 
implemented by clients themselves, with only small modifications to BitCoinJ.

1. Before shutting down PeerGroup, get hosts+ports of all connected peers and 
persist them. Would need some API on Peer, also see issue 158.

2. When starting PeerGroup, first add a self implemented PeerDiscovery that 
delivers the previously persisted peer addresses, then add the usual 
Dns/IrcDiscovery. Some contracts about PeerGroup/PeerDiscovery would be needed:

First, if multiple PeerDiscoveries are added to a PeerGroup, the discovery 
mechanisms should run in parallel.

Second, PeerGroup should use each return value of getPeers() only once and be 
forced to ask PeerDiscovery again if it needs new addresses.

Third, implementations of PeerDiscovery should be able to say "I'm out of 
addresses" which causes PeerGroup to forget about that particular PeerDiscovery.

Original comment by andreas....@gmail.com on 16 Mar 2012 at 12:50

[GoogleCodeExporter]

Sure, that all makes sense, but we may as well have the persistable 
PeerDiscovery in the library as well. It's not much code once the rest is 
completed.

Original comment by hearn@google.com on 16 Mar 2012 at 12:54

[GoogleCodeExporter]

Thinking some more about it, it's probably even easier to use 
PeerGroup.addAddress() for the initial set of peer addresses.

Original comment by andreas....@gmail.com on 16 Mar 2012 at 1:00

[GoogleCodeExporter]

I implemented this with minimal impact in commit 
2e49ff92a17e8346ba0766a4175709957543bed7 on my branch 
fast-connect-to-last-peers.

The only thing I need is exposing of a Peer's peerAddress so I can write those 
to a file.

Also, a fix to issue 159 is needed badly. Unreachable peers will cause BitCoinJ 
to loop forever though connection retries and never (re)discover peers.

Original comment by andreas....@gmail.com on 16 Mar 2012 at 9:22

[GoogleCodeExporter]

Original comment by hearn@google.com on 8 Jan 2013 at 4:42

• Added labels: Component-Network