Randomized picking of peer to request space from is not random

[bboreham]

Neither weave's picking of a random number nor Go's picking of a random order to iterate the hashtable is seeded, so they always pick the same ones, for a given set of start conditions.

[rade]

What is the user-visible manifestation of this?

[bboreham]

Supposing the particular node picked does not respond, and no error gets back to the caller; e.g. messages are dropped by an intermediate peer, then the user may restart weave and try again, then weave will pick exactly the same peer, so if the same conditions result in no response then this will be user-visible.

Post- #1010, this is a much more unlikely scenario.

[rade]

So we could either initialise our own random source, or seed the global source with rand.Seed( time.Now().UTC().UnixNano()). I am tempted to do the latter, especially since NewSource does not return thread-safe sources, so we'd have to re-invent the locking that golang has kindly hidden for us in the unexported lockedSource which is used by the global source.

The question is where to put that seeding call. It seems dodgy to place it in an init() in a library, since then multiple initialisations can occur (which is ok, I guess, except when they occur in the same nanosecond). I see that your friends at Hashicorp don't seem to be bothered by this - serf includes memberlist and both have an init() that seeds the global random source.