.Now that IRC is partitioned we won't actually see most nodes coming and going, so excluding these nodes greatly increases the amount of clique formation.
This was bad even before the channel split because the /who output was limited, so we'd end to stop connecting to long running stable nodes.
selection.
Now that IRC is partitioned we won't actually see most nodes coming
and going, so excluding these nodes greatly increases the amount of
clique formation.
This was bad even before the channel split because the /who output
was limited, so we'd end to stop connecting to long running stable
nodes.
How can we test this to make sure it makes connectivity better instead of the same or worse?
I'm not sure how to test it well, but it makes sense. Preferring nodes that just happen to be in the same irc channel we are is always going to leave a large chunk of good connectable nodes out of the list of possible outbound connections and could eventually lead to island networks in some cases.
I've been running it on a node for a week after I observed that it was only had outbound connections to hosts in the same IRC channel. It has two now.
It doesn't completely fix the behavior. Because IRC updates the addr.nTime and the time since then is used to control the retry interval it makes nodes much more likely to connect within the channel they are in. But at least with this patch they won't have a zero chance (after the first connection).
One piece of evidence of this patch's probable safety is that this check also doesn't run for nodes which have IRC disabled, and isn't applied when there is only one connection. Also, the significant majority of nodes listed on IRC (which would get included by this check) are not listening already. So the fact that this check may cause a few more long unreachable nodes to be tried shouldn't be harmful.
More needs to be done wrt. pruning addr.dat, excluding non-listening nodes, connection rotation, etc. If IRC is retained by default (I don't know what the core dev's plans are for that) then I'll go ahead and submit patches for multi-join (listening nodes should join two channels) and periodic channel hop (every n-hours switch to another channel), both of which I have working but didn't bother cleaning up for submission because I didn't expect bitcoin to keep IRC on by default for long.
Er. github lost the last comment I wrote.
I'm closing this for now because I also want to fix another issue at the same time where the client can get stuck unable to make new outgoing connections, as I'm concerned that it may be worse in the no IRC case (and after this patch). I think whats happening there is that once all remaining nodes have last tried greater than the minimum used in the score, that the ranking becomes completely stationary and it only ever tries one node (until some lucky IRC activity perturbs the order).
It's going to take me a day to to collect data from an instrumented node to confirm I understand that bug, and a day to confirm that my fix is correct. So I suppose this should wait until then. Sorry for the premature request.