connection handling modularization#857
Merged
Merged
Conversation
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.
The main purpose of this PR is to modularize the communication library, and streamline the code paths for TCP and UDP into a single flow. This will help us add additional flows such as TLS, and also make sure these communication functions return a known set of error codes so that additional error codes can be added for new flows in the future.
It also adds a new optional callback of
ares_set_notify_pending_write_callback()that will assist in aggregating data from multiple queries into a single write operation. This doesn't apply to UDP, but on TCP and especially TLS in the future this can be a significant win. This is automatically applied for the Event Thread.It also fixes a long standing issue if UDP connection became saturated and started returning
EWOULDBLOCKorEAGAINit was treated as a failure. Since this is more inline with the TCP code now, it will wait on a write event to retry.Finally there are additional cleanups due to not needing to be able to retrieve socket errnos all over the place.
Authored-By: Brad House (@bradh352)