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.
There is no point, and it populates the cache with entries we don't
need. Local containers will still need to issue an ARP request when
they first talk to an IP corresponding to the MAC, so we learn about
the MAC at that point, just as normally happens.
This was rather impenetrable and had some significant code
duplication. So add some words of explanation, and refactor to remove
the duplication.
Some fly-by fixing of minor bug too: buildUnicastRoutes failed to
exclude asymmetric connections from the first hop.
Golang locks aren't re-entrant. As result one can get deadlocks on
RWMutexes like this:
goroutine #1: attempt to acquire read lock -> success
goroutine #2: attempt to acquire write lock -> wait
goroutine #1: attempt to acquire read lock again -> wait
(a pending write lock prevents subsequent acquisitions of read locks)
Peer.HasPathTo could run into this since it could attempt to acquire
the read lock on a peer multiple times if previously it had
encountered that peer via an asymmetric connection.
We don't need. Multicast addresses never appear as sources and hence
never end up in the peer_cache. And the router always broadcasts
frames with destination addresses that aren't in the peer cache.
Matthias Radestock