O1 implementation for handlers signal

[leoparente]

[leoparente]

Premises

1. matcher is the one that will look all or part of the traffic and call InputEventProxy send_metadata
2. matcher needs to implement call logic and validate its key metadata
3. match is the one that will be called only if its key value pair matches (O(1))
4. match handler will only be created if there is a matcher registered with same key
5. match and matcher must have the same schema (e.g. "dns")
6. match is code agnostic. It allows to connect custom handlers matchers with standard handlers match as long as they have the same schema and key metadata.

[leoparente]

Based on image above we have the call hierarchy for DNS UDP traffic:

1. All Traffic Policy DNS Handler will be the matcher, so it register itself as any other module to PcapInputEventProxy udp_signal.
2. Google Policy and Amazon Policy DNS Handler are matches, so instead of registering to udp_signal, they perform PcapInputEventProxy::register_udp_predicate_signal to register a callback to be called when the match occurs.
3. When a packet arrives and it is UDP packet, PcapInputEventProxy::process_udp_packet_cb is called and it calls udp_signal which will trigger All Traffic Policy DNS Handler call.
4. As All Traffic Policy Policy DNS Handler is a matcher, it will call PcapInputEventProxy::send_metadata that will enable the flag _any_match
5. After udp_signal finishes calling all registered signals, PcapInputEventProxy::process_udp_packet_cb method will check if there is any match and if so, it will call the matches registered callbacks (O(1))

-process_udp_packet_cb
---udp_signal starts
-----send_metadata
-------udp_signal ends
---------any_match?
------------predicate_udp_signals find
---------------specific signal call

[weyrick]

is this still dependent on the order of the policies? i also cannot wrap my head around the names of the concepts here, i will try to think of different names that might be more intuitive.

[leoparente]

is this still dependent on the order of the policies? i also cannot wrap my head around the names of the concepts here, i will try to think of different names that might be more intuitive.

It still. @rboucher-ns1 would propose something at Handler level and not policy level. So we should discuss that

[leoparente]

@weyrick Just noticed that with that approach we loose the feature to track filtered out counter because the function that track it is never called

[rboucher-me]

@weyrick Just noticed that with that approach we loose the feature to track filtered out counter because the function that track it is never called

That's a small (and acceptable) price to pay

[weyrick]

@weyrick Just noticed that with that approach we loose the feature to track filtered out counter because the function that track it is never called

That's a small (and acceptable) price to pay

Cool ok let's accept losing it for now then. I think there may be options in the future to add it back (based on failing predicates) but adds complication so let's avoid if we can.