rtpproxy: drain timeout notification sockets#3911
Open
sobomax wants to merge 1 commit into
Open
Conversation
RTPProxy may keep the notification connection open while writing a burst of timeout events. The rtpproxy notification callback only performed a single read per reactor wakeup, so already-buffered notifications could be left pending with no further event to wake the process. Set notification sockets nonblocking and drain them until EAGAIN, preserving partial commands between callbacks. Also centralize notification connection cleanup so error, EOF and handler failure paths consistently unregister the fd, free pending data and close the socket.
Contributor
Author
|
P.S. Tested with both rto.io and external notification socket. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
RTPProxy may keep the notification connection open while writing a burst of timeout events. The rtpproxy notification callback only performed a single read per reactor wakeup, so already-buffered notifications could be left pending with no further event to wake the process.
Details
This issue has been uncovered while working on an extended version of the voiptests that would also test "no-media notifications". As a result of this bug, only first few notifications are processed. The notification queue after that stalls and never recovers effectively making notifications disabled. The bug has been introduced somewhere along 3.2 timeline, when notification has been refactored to use reactor.
Solution
Set notification sockets nonblocking and drain them until EAGAIN, preserving partial commands between callbacks. Also centralize notification connection cleanup so error, EOF and handler failure paths consistently unregister the fd, free pending data and close the socket.
Once committed, the new version of voiptests will be pushed to make sure this won't get broken again.