The delay d(n) for the nth retry was
d(1) = rand(initial_interval)
d(n+1) = d(n) + rand(d(n))
There are two problem with this:
1) The entire sequence is dominated by the random value for d(1). If
this is a small value, lots of retries at short interval ensue. In
extremis, if d(1) is 0, indefinite immediate retries would ensue.
2) The delay is not a true exponential backoff; the upper bound only
increases exponentially *probabilistically*.
The new algorithm calculates
d(n) = random_value in range [i-i/2,i+i/2],
where i = initial_interval * 1.5^(n-1).
Thus d(1) is at least initial_interval/2, and successive values are
independent of previous values, forming a true exponential sequence of
intervals bounds between which the retry delay is chosen randomly.
Due to the change in algorithm we reduce...
- the initial interval from 5s to 2s. Recall that previously d(1) was
in the range [0,initial_interval=5s]. It is now [2-2/2=1s,2+2/2=3s].
- the max interval from 10 minutes to 6. Previously, once that was
reached, it would stay exactly there. It is now randomly chosen in
the range [6-6/2=3m,6+6/2=9min].
Thus previously delays would range from 0 to 10 minutes, now they
range from 1s to 9 minutes.
Fixes#412.
If a peer was specified on the command line w/o a port, then do not
connect to it if we have inbound connections from that IP.
This eliminates unnecessary (and ultimately failing) connection
attempts in the common scenario of several peers having been told
about each other on their command lines.
We represent a command line peer address with a TCPAddr, which avoids
back and forth conversion to string and extra fields to carry the "did
the original include a port?" information.
This got broken in 6409a8647c
The issue is that for successful connections nothing ever sets
attempting=false, so we need some other means of removing such
entries.
There is no need to remove entries from cm.targets that are in
ourConnectedTargets. None of these targets will be in validTargets
(since addTarget filters anything in ourConnectedTargets), so they
will be removed a few lines further down anyway...
Unless the target is in the 'attempting' state. But that is ok, and in
fact desirable. Any such targets indicate connection attempts that are
in progress, which is something we display in `weave status` and want
to be accurate. Eventually the connection attempt will either succeed
or fail, and the cm.targets entry will be removed on the next run of
connectToTargets.
This commit adds two command line options, intended to allow multiple
instances of weave to run without container separation between them.
* -port=PORT makes weave bind to port PORT (an integer). Without the
option, the default value (6783) is used.
* -httpaddr=ADDRESS makes weave bind its control interface to
a different address. For instance "127.0.0.1:6784" can be used to
bind to localhost only. An absent address element makes it bind to
all interfaces. ":6784" is the default. An empty string
can be used to disable the control interface.
Signed-off-by: Alex Bligh <alex@alex.org.uk>
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