Added context capabilities to the peek context so one does not need to implement callbacks for every event type if there are multiple.

Especially if you want to "peek" into the future for a certain kind of event, this might be necessary.

I'm not sure peeking into the timers list is a good idea.

Your use-case is "send RA only if next RA is more than X time away (or not scheduled)", right?
Having to traverse the timer list for every single peek seems too expensive.

Your use-case is "send RA only if next RA is more than X time away (or not scheduled)", right?

It's even a little bit more complicated I realized. It's more like: if between 0 and X time units no NS is scheduled send now, if between X and 2X time units no NS is scheduled send in t

Having to traverse the timer list for every single peek seems too expensive.

More expensive then broadcasting unnecessary messages?

Having to traverse the timer list for every single peek seems too expensive.
More expensive then broadcasting unnecessary messages?

More expensive than thinking a little bit on what you want to achieve.
Your requirement is not "look at the list of scheduled NS in order to find out whether to send now or in t".
How many NS are scheduled at any time? If the answer is zero or one (per peer/iface/whatever), just save the time of that in a struct of your choice.

How many NS are scheduled at any time? If the answer is zero or one (per peer/iface/whatever), just save the time of that in a struct of your choice.

<=3 multicast (per interface) when an unknown neighbor is to be resolved, <=3 unicast for any known neighbor when NUD is performed. Also rate-limited are multicast RAs and multicast NAs (both per interface). For a scalable network that's a lot of 32-bit numbers (in typically scarcer RAM) to save some bytes in ROM considering that the time is already saved in this event queue.

Rebased.

<=3 multicast (per interface) when an unknown neighbor is to be resolved, <=3 unicast for any known neighbor when NUD is performed. Also rate-limited are multicast RAs and multicast NAs (both per interface). For a scalable network that's a lot of 32-bit numbers (in typically scarcer RAM) to save some bytes in ROM considering that the time is already saved in this event queue.

So you're scheduling all of them at once? Why not schedule one event to trigger the first and when it get's sent, schedule the next?

So you're scheduling all of them at once? Why not schedule one event to trigger the first and when it get's sent, schedule the next?

You mean the messages of same type or in general?

Every neighbor gets solicitations, right? And every interface gets RS. So now with N neighbors, you could schedule N*M (M<=3) solicitation packets (which was your original plan the way I read your use-case).
Or you could, per neighbor, schedule only the next NS and a count how many you've already sent. Same for each interface with router solicitations. That way you'd have to save two integers and one timer per peer/interface/..., which is already less than >=2 timers per peer/interface/...

schedule only the next NS and a count how many you've already sent.

Sorry, I mean, schedule the next, and remember when that should trigger and how many you've already sent.

I've merged the uncrustify, milliseconds, ENABLE_DEBUG, casting fixes.

Every neighbor gets solicitations, right? And every interface gets RS. So now with N neighbors, you could schedule N*M (M<=3) solicitation packets (which was your original plan the way I read your use-case).
Or you could, per neighbor, schedule only the next NS and a count how many you've already sent. Same for each interface with router solicitations. That way you'd have to save two integers and one timer per peer/interface/..., which is already less than >=2 timers per peer/interface/...

No sorry that was really confusingly stated by me: of course I will only schedule the next NS. Let me think about (and try out) your proposal first.