Skip to content
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

Close TCP connection in case of error #384

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

antoninbas
Copy link
Member

This is better than keeping the connection open, as it sends a signal to the exporter that something is wrong.

This is also one of the four possible behaviors described by RFC7011 for handling malformed IPFIX messages for TCP and SCTP connections. See https://datatracker.ietf.org/doc/html/rfc7011#section-9.1. Note that implementing one of these four options is not mandatory. However, the RFC also states that:

the Collecting Process SHOULD stop processing IPFIX Messages
from clearly malfunctioning Exporting Processes (e.g., those from
which the last few IPFIX Messages have been malformed).

Closing the TCP connection is the easiest thing for us to implement, and it makes sense to use IMO.

This is better than keeping the connection open, as it sends a signal to
the exporter that something is wrong.

This is also one of the four possible behaviors described by RFC7011 for
handling malformed IPFIX messages for TCP and SCTP connections. See
https://datatracker.ietf.org/doc/html/rfc7011#section-9.1. Note that
implementing one of these four options is not mandatory. However, the
RFC also states that:

> the Collecting Process SHOULD stop processing IPFIX Messages
> from clearly malfunctioning Exporting Processes (e.g., those from
> which the last few IPFIX Messages have been malformed).

Closing the TCP connection is the easiest thing for us to implement, and
it makes sense to use IMO.

Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
go func() {
defer cp.wg.Done()
defer close(doneCh)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could also be considered a bug fix. Prior to this commit, return statements in the for loop would cause this goroutine to return, but we would block on cp.stopChan indefinitely (so I think there would be a goroutine leak, as the parent goroutine, which invoked handleTCPClient would never return).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants