Instead of following the usual actor pattern, we use a 1-place channel
with a non-blocking send. Essentially, if there is already a pending
recalculation request queued up, there is no point enqueuing another
one.
I can get 29 weaves running on my laptop, and once all connections are
established, the avg cpu load is ~10%. 30 runs into difficulty because
the concurrent connection establishment does create a very high load,
resulting in some timeouts. But that wouldn't happen when running each
weave in a separate machine (with more CPU resources overall than my
single laptop).
Stop gap solution for #426.
which allows launching of several weave routers on the same machine,
by invoking this multiple times with different WEAVE_CONTAINER_NAMEs.
The routers are not connected to the bridge and do not perform any
capture/injection. So this is mainly intended for testing of
administrative and control plane functionality, rather than routing.
- make Zone, Iface and Upstream public - this is safe and makes sense
since all are immutable, and the former two are passed to the
constructor and are thus known anyway, and the latter is derived
from external information
- remove IfaceName - we can just use Iface instead
- log Upstream on startup
same purpuse as WEAVE_DOCKER_ARGS, except for weavedns
This allows us to get rid if the -fallback option since
WEAVEDNS_DOCKER_ARGS="--dns=..." has the same effect.
Closes#487.
we simply reset the vars controlling backoff for that address
Note that we do not interrupt any current connection attempt, since
that is hard.
Closes#499.
d5eb76f32 replaced (*Peer)ForEachConnection into (*Peer)Connections(),
and consequently converted some nested functions into for loops. But
the "return" statements in those nested functions were left as-was,
and so exited the outer function rather than moving on to the next
iteration.
Fixes#497
Matthias Radestock