-
Notifications
You must be signed in to change notification settings - Fork 431
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
feature(event): create net_flow_tcp_begin event #3750
Conversation
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.
I have a question on approach:
You've chosen to basically create a "fake" flow tcp base packet, and do the standard derive from base to actual.
But you could've just as well appended the flow flag to the regular base tcp packet and added another derive function there, without adding an additional "fake" base packet. I think it would've been more readable, at the cost of more derivation entries (though maybe we could've done double derivation here base->tcp->flow).
So just wanted to know why you chose this approach.
Take note of my first comment on trace.PakcetMetadata
too please.
Overall I've also added suggestions below, and I think the logic by its own is sound.
Im doing some refactoring now to address suggestions and improve the base network code. |
- create net_flow_tcp_begin event derived from a net_packet_tcp_flow_base. The base event is only submitted to userland whenever TCP has SYN and ACK flags. It will also submit packets with FIN flags for the future `net_flow_tcp_end` derived event (but it needs some state keeping so not done now). > Differently than ACK+SYN combination flags, which allows observer to know the > direction of the connection (egress with ACK+SYN the connection is incoming > to host, ingress with ACK+SYN the connection is outgoing from host), the FIN > flag might come in either direction, with or without an ACK, so existing > connections state must be kept in order to know when the flow has ceased to > exist.
- add the base for keeping flow states (for future stats) - flow states allow knowing end flows for tcp and udp
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.
LGTM
👇 PR Comment BEGIN
8b88ac2 feature(network): add network flow end base for events
34b6682 chore(derive/net_packet): refactor derivation functions
fd0b8da chore(review): no need to check amount of ret variables
12a144d feature(event): create net_flow_tcp_begin event
e2eaabc docs(network): add net_tcp_connect and net_flow_tcp_begin docs
8b88ac2 feature(network): add network flow end base for events
12a144d feature(event): create net_flow_tcp_begin event