Better documentation, error messages, defaults regarding the gige socket-buffer-size #898
Conversation
This file contains 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
No-op patch. The win32 and non-win32 paths are actually identical, and after this patch, that fact is immediately clear
More diagnostic output. More error checking. More detailed error messages. I routinely observe setsockopt(SO_RCVBUF) ask for a buffer of a particular size, the function returning successfully, but the actual buffer that ended up allocated being smaller. This condition is now reported as an error
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
These are the result of me encountering and debugging packet-dropping issues: #894
Primarily these patches add more error reporting and documentation. With the extended error messages I think it makes sense to change the default socket-buffer policy to
ARV_GV_STREAM_SOCKET_BUFFER_AUTO, which this patch series does.There's one more thing I would change also, but want to get your thoughts about all this first:
If setsockopt() returns success, but doesn't actually give us the requested buffer, we currently:
arv_warning_interface()arv_socket_set_recv_buffer_size()returns FALSEBut the caller of
arv_socket_set_recv_buffer_size()doesn't do anything with this FALSE, and things continue as normal. I would make this a hard error, and I'd change thearv_warning_interface()to something that would be seen even without anyARV_DEBUGflags.Thanks much