I think it would make more sense to do the initial random delay on the background threads.
I think it would make more sense to do the initial random delay on the background threads.
I did consider that. The delay is only intended to be once per message. I could do simultaneous identical delays on each background thread, or I could have a 'delay' thread that then spawns the background threads, instead. For simplicity though I felt I'd just leave the initial delay on the main thread. It does mean there is a slight delay on the main thread compared with Windows when a 'hello' or 'probe matches' message is sent, but compared with the initial version of my patch (which included retransmission delays for every adapter on the main thread) it is much improved.
If however you feel strongly that this should be altered, I can submit an updated version.
Cheers,
Why would it be the same for each interface and protocol? If the purpose is to prevent one big spike of traffic, it seems like you'd want different delays.
On Fri, Aug 4, 2017 at 4:34 AM, Owen Rudge owen@owenrudge.net wrote:
I think it would make more sense to do the initial random delay on the background threads.
I did consider that. The delay is only intended to be once per message. I could do simultaneous identical delays on each background thread, or I could have a 'delay' thread that then spawns the background threads, instead. For simplicity though I felt I'd just leave the initial delay on the main thread. It does mean there is a slight delay on the main thread compared with Windows when a 'hello' or 'probe matches' message is sent, but compared with the initial version of my patch (which included retransmission delays for every adapter on the main thread) it is much improved.
If however you feel strongly that this should be altered, I can submit an updated version.
Cheers,
-- Owen Rudge http://www.owenrudge.net/
-
Owen Rudge -
Vincent Povirk