-
-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add flow risks #151
base: master
Are you sure you want to change the base?
Add flow risks #151
Conversation
@stefanDeveloper Thanks a lot for your valuable contribution. I will review next week . Thanks! |
This looks like a promising feature. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stefanDeveloper Can you please make these changes. I'm planning to merge it before the next release.
Many Thanks!
@aouinizied @stefanDeveloper Should the flow risks be perhaps one hot encoded rather than in the current format? That would be way more suitable for any ML use. In that case, there could probably be a streamer attribute to enable/disable flow risks output. The current format when exported to CSV is rather unusable. |
Representing the risk itself as one-hot encoded is a valid point. |
@stefanDeveloper One hot encoding is part of the post processing. We do not have to deal with it at this point. |
That would normally be true. But because of the way how currently the |
Can you quantify how much overhead flow risk calculation brings to NFStream's basic functionality? |
@smith558 I understand your point. Switching to a format where the key is the risk and the value is a pair of cli/src scores will make this easier (but still imperfect). Zied |
@drnpkr This is not an easy question. The overhead for a feature depends of several stages.
Today, NFstream relies on Pipe as IPC and default pickle for serialization. A dummy feature that is stored somehow in a complex object can result in an overhead that is coming from serialization. We can assess later the overhead of risk analysis by disabling manually all export between streamer and meters replacing each meassage by the same dummy flow export. |
Not easy, indeed, but a relevant one. You might remember that we observed a performance drop at higher speeds. Having new features are fine but we should be aware of its costs. Nonetheless, I agree that this can be evaluated at some later point. A note shall be put somewhere that this can have certain limitations on the performance. At least until it hasn't been tested. |
Any idea why the pipeline for windows is failing? |
Have you had time review the changes to resolve your change requests? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add a test for it?
@aouinizied I've rebased my branch to resolve the merge conflicts and added a tests. |
Add nDPI flow risks
Description
I have added the flow risks of nDPI. I adapted the
lib_engine.c
and the python wrapper, respectively.Info:
I will update the documentation and tests if this general approach is alright.
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Results in:
Test Configuration:
Linux nixos-work 5.15.85 #1-NixOS SMP Wed Dec 21 16:36:38 UTC 2022 x86_64 GNU/Linux
Checklist: