Parallel gossiping

[rahulghangas]

As title

[rahulghangas]

CI fails for now, will work with the fix in #73 after it is reviewed and merged

[ross-pure]

I'm not in favour of this change. This PR spawns each call to transport.Send in it's own go routine, but I think this is potentially less efficient than making the calls sequentially. All that transport.Send does in the case that the peer is already linked is write to a buffered channel, and if it is not linked then it calls dial in a go routine. In total this is not really enough work to warrant being done in parallel in my opinion.

I tested how long each gossip takes in the gossip test with and without this change, and on my laptop the times were indistinguishable.

EDIT: Forgot to mention that spawning go routines for each send is probably worse on the whole because of the additional resources required for the go routines and the unnecessary extra work they give to the scheduler.

[rahulghangas]

@ross-pure this came after an issue we (I and Jaz) discussed regarding gossip timeouts. We opted for the parallel solution because if the first send call blocks (stuck in dial), it can potentially cause the other peers to not receive the gossiped message

[ross-pure]

@rahulghangas But it looks like any potential call to dial is in a go routine already, specifically I'm looking at transport.go:160 and transport.go:168

[rahulghangas]

You are right. In that case, there is indeed no need to parallelize the Send(..) calls. I'll close the issue