nDPI
nDPI copied to clipboard
Add new API call for detection setup
Currently it is the nDPI caller that decides when a given flow has been detected or not. In order to clean library internals it would be desirable to add a new API call where the caller specified what is the max number of UDP/TCP packets after which detection fails.
Regarding this, ignoring any performance issues, how would the caller know what the optimal number of packets would be to ensure nDPI receives enough packets per flow to optimally identify protocols?
From an nDPI caller point of view, I would ideally like to get some indication from the library what the minimum number of packets per UDP/TCP flow need to be to identify all supported protocol dissectors. I'm assuming different protocols have different minimum number of packets that need to be analyzed to make a positive match, or maximum number before the dissector knows it's not a match?
As an example, something like the following would be ideal from a caller/user perspective:
int max_udp_packets = ndpi_suggested_max_udp_packets_per_flow();
int max_tcp_packets = ndpi_suggested_max_tcp_packets_per_flow();
max_udp_packets = max_udp_packets < my_max_permitted_packets ? max_udp_packets : my_max_permitted_packets;
max_tcp_packets = max_tcp_packets < my_max_permitted_packets ? max_tcp_packets : my_max_permitted_packets;
ndpi_init_detection_module(......, max_udp_packets, max_tcp_packets);
Do the dissectors currently expose something like this to nDPI main so it can build the max number of suggested packets?
Great idea but this is v2 of this issue:
- v1: tell nProbe when the library should give up (in the worst case) for detection
- v2: specify, per protocol, the max number of packets. For instance for DNS it will be 1 (or 2 if we want to see req/reply) instead for HTTP it will be much more.
Is there a way to find out the state of a flow detection process? Thanks.
Issue already solved. The preference ndpi_pref_max_packets_to_process
can be used for such cases.