tinc 1.1: missing PONG

[Todd C. Miller]

On Mon, 26 Feb 2018 23:01:29 +0100, Guus Sliepen wrote:

> The problem is not the order of the events, the problem is that in the
> Windows version of the event loop, we only handle one event in each loop
> iteration. The select() loop handles all events that have accumulated so
> far, so regardless of the order it handles them, it never starves fd. At
> least, that was what I thought, until I double checked and found out
> that we actually don't in tinc 1.1 (tinc 1.0 is correct though).

Sure, but changing the order of the events changes which one will
be in that first slot.

> So, we have to find a proper fix for both the POSIX and Windows variants
> of the event loop in 1.1. For POSIX, the issue is that we might
> invalidate the loop iterator due to a callback. It should be easy to
> detect that and only exit the loop early if that's really the case. I'll
> do that.

How would you detect that?  By checking whether the next node has
changed?

> For Windows, there are two issues that have to be fixed. First is
> that we only handle a single writable IO event. The second is that
> WSAWaitForMultipleEvents() only returns one index into the array of
> events, even though multiple events might have triggered. How hard would
> it be to check for all triggered events?

I don't think it is too hard.  I was working in that direction
initially but wasn't sure if a larger change would be welcome.
I'll take a stab at it.

> > With this change I can no longer reproduce the problem of nodes not
> > responding to pings.
>
> This will merely move the problem to some other filedescriptor.

Changing the order of the events changes the index of which event
is returned by WSAWaitForMultipleEvents().  Moving the most recently
accessed event to the end gives the others a chance to proceed.

 - todd