ConnectionMaker requirements

MUST

1. attempt to establish connections to the addresses provided on command line
2. re-attempt to establish connections to the addresses provided on the command line in the event of failure of the initial connection attempt
3. attempt to establish connections to new peers we learn about
4. re-attempt to establish connections to peers we know about in the event of failure of connections to those peers
5. not establish connections to peers we don't know about, except through the addresses provided on the command line
6. not maintain multiple connections to a single peer (*)

(*) This is currently handled by the connection/peer code, rather than ConnectionMaker. Unless there is a compelling reason to change that I'd keep it that way.

SHOULD

1. attempt to establish connections to command line addresses immediately on startup
2. re-attempt to establish connections to peers immediately after detecting a failure
3. back off the connection attempt interval
4. not attempt to establish concurrent connections to the same address
5. not attempt to establish more connections when we are already connected to all known peers and have established connections to the command line addresses

COULD

1. attempt to establish connections to known, currently unconnected, peers only at the command line addresses and the specific addresses we learnt about the peers.

Without C1, if we learn that P1 can be found at A1 and A2, P2 at A3 and P3 at A4, and we have established a connection to P1 at A1, then we'd attempt to connect to A2, A3 and A4, and don't care at which of these addresses we find P2 and P3. With C1 we'd attempt to connect to A3 and A4 only, and check that if we do succeed then the connected peer is indeed P2 and P3, respectively. There are a couple of complicatinos though...

• What should happen when A3=A4? With S4, we should only attempt to establish one connection. Presumably we should be happy to find P2 or P3 at the other end, but no other peer.
• If we happen to find another known, but currently unconnected, peer P4, at A3/A4, why would we not be happy to keep that connection?

So is C1 in fact desirable? The main benefit it brings is that we won't be making "pointless" connection attempts. Without C1, if there is just a single unconnected peer, and just a single unconnected address we know about, then we will keep trying to (re)connect there even when a) we find another peer there, to which we are already connected, and hence drop the new connection, or b) the address is one we will never be able to connect to, due to firewalls etc, but does in fact belong to another peer (and that's what the topology info told us).

The current ConnectionMaker fails M2, S2, S4.

A minimal compliant implementation, satisfying all MUSTs but not SHOULDs & COULDs, might:

• keep the list of command line addresses and keep attempting to establish connections to them, not caring about what peers we find at the other end
• keep a list of other addresses - those found through topology discovery and not in the command line address list - and keep attempting to establish connections to them, checking that the peer we find at the other end is a peer we know about.

A couple of key observation:

• The distinction between command line addresses and other addresses is crucial.
• The association between peers and addresses is unimportant except for C1.