There is no need to go via Topology. Fetching does not access or
modify the Topology state, and none of the functions on Topology
update the PeerCache. So there is no point serialising the fetching
with RebuildRoutes (or anything else).
This does mean the connections' receiveTCP goroutines will take a
direct lock on PeerCache, but a) it is only a read lock, and b) they
already take a write lock in another code path.
There may be some extra load on the PeerCache as a result of this
change, due to the topology fetching of multiple connections no longer
being funneled through the single Topology goroutine. Consequently,
write locks on the PeerCache may take a little longer to
acquire. Until we encounter this as a genuine problem though it's
better to stick with the simpler code.
The weave protocol already effectively performs heartbeating -
FetchAll is performed at regular intervals. Hence we can detect stale
connections by the lack of receiving any data for approximately that
interval (we use x2).
We use the same interval to set a time limit on the handshake too, and
any subsequent interactions prior to the connection being fully
established.
Fixes#272.
...by moving the logic into the connection actor goroutine.
The heartbeater goroutine was doing a lot more than just heartbeating;
namely it also had tickers for triggering a ProtocolFetchAll and
initiating a fragmentation test. Furhermore, ensureHeartbeats also
spawned the forwarders.
So this was quite a mix of functionality, and, furthermore, most of it
related quite closely to the connection actor. So moving the
functionality into that simplifies the code.
In the process we also fix#294.
Matthias Radestock