dankamongmen / libnetstack

Small library around rtnetlink to track networking stack elements
https://nick-black.com/dankwiki/index.php/Libnetstack
Apache License 2.0
10 stars 0 forks source link

MOD event can be provided to user before NEW event #16

Open dankamongmen opened 5 years ago

dankamongmen commented 5 years ago

Imagine the following interleaving:

currently, this would result in the user seeing a MOD followed by a NEW. maybe that's no problem. in that case MOD vs NEW seems a useless thing to distinguish, and we ought not provide this semantic. if it is useful, we need to avoid this. we don't want to just drop the MOD. either we could present the MOD as a NEW, and drop the dump result, or we can hold the MOD until we get the dump result, and then send them both.

this last seems a lot of state for not much value. i say we pass along the MOD and drop the dump result. simply failing to distinguish means that we would send the MOD followed by the NEW, meaning the user possibly ends up with stale state. there are orderings where the NEW would have more up-to-date information than a MOD that came before it, but all such situations seem to require a change following our request for a dump, which will generate a new MOD event with the up-to-date information.

so i think the way forward is:

to be completely robust, this last line (filter dumps if we've sent a message about this device) need to take into account delete events. consider this ordering:

this is solved by treating DEL exactly like MOD for purposes of dump response handling, though it does require some annoying state we wouldn't otherwise need (to track deleted objects, at least up through the dump response).

a lot of effort to handle race conditions on initialization :(. gotta do it, though.