Do not wait connection attempt delay without in progress fds #12087
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
Reset Connection Attempt Delay when connection fails and there is no other socket connection in progress. This is intended to resolve an issue that was temporarily worked around in Pull Request ruby#12062. `TCPServer::new` (used in tests such as `TestNetHTTP_v1_2_chunked#test_timeout_during_non_chunked_streamed_HTTP_session_write`) can only connect over either IPv6 or IPv4, depending on the environment. Since HEv2 attempts to connect over IPv6 first, environments where IPv6 connections are unavailable return ECONNREFUSED immediately. In such cases, the client should immediately retry the connection over IPv4. However, HEv2 includes a specification for a "Connection Attempt Delay," where it waits 250ms after the previous connection attempt before starting the next one. This delay causes Net::OpenTimeout (100ms) to be exceeded while waiting for the next connection attempt to start. With this change, when a connection attempt fails, if there are sockets still attempting to connect and there are addresses yet to be tried, the Connection Attempt Delay will be resetted, allowing the next connection attempt to start immediately. --- Additionally, the following minor fixes have been made: - The `nfds` value used for select(2) is now reset with each wait.
aa797a0 to
b2f610b
Compare
shioimm
added a commit
to shioimm/ruby
that referenced
this pull request
Nov 30, 2024
… connection failure. This change addresses a case that was overlooked in ruby#12087. In the previous change, the Connection Attempt Delay was cleared at the point of a connection failure only if both of the following conditions were met: - No other sockets were attempting a connection - There were addresses still available to start a new connection In this update, the second condition has been removed. As a result, if name resolution succeeds after a connection failure and new addresses are obtained, it will be able to immediately attempt a connection to one of them. If there are no sockets attempting a connection, no addresses available for connection, and name resolution has completed, an exception will still be raised as before.
shioimm
added a commit
to shioimm/ruby
that referenced
this pull request
Nov 30, 2024
… connection failure This change addresses a case that was overlooked in ruby#12087. In the previous change, the Connection Attempt Delay was cleared at the point of a connection failure only if both of the following conditions were met: - No other sockets were attempting a connection - There were addresses still available to start a new connection In this update, the second condition has been removed. As a result, if name resolution succeeds after a connection failure and new addresses are obtained, it will be able to immediately attempt a connection to one of them. If there are no sockets attempting a connection, no addresses available for connection, and name resolution has completed, an exception will still be raised as before.
shioimm
added a commit
to shioimm/ruby
that referenced
this pull request
Nov 30, 2024
… connection failure This change addresses a case that was overlooked in ruby#12087. In the previous change, the Connection Attempt Delay was cleared at the point of a connection failure only if both of the following conditions were met: - No other sockets were attempting a connection - There were addresses still available to start a new connection In this update, the second condition has been removed. As a result, if name resolution succeeds after a connection failure and new addresses are obtained, it will be able to immediately attempt a connection to one of them. If there are no sockets attempting a connection, no addresses available for connection, and name resolution has completed, an exception will still be raised as before. Additionally, the following minor fixes have been made: - Refactor: Remove unnecessary members
shioimm
added a commit
to shioimm/ruby
that referenced
this pull request
Nov 30, 2024
… connection failure This change addresses a case that was overlooked in ruby#12087. In the previous change, the Connection Attempt Delay was cleared at the point of a connection failure only if both of the following conditions were met: - No other sockets were attempting a connection - There were addresses still available to start a new connection In this update, the second condition has been removed. As a result, if name resolution succeeds after a connection failure and new addresses are obtained, it will be able to immediately attempt a connection to one of them. If there are no sockets attempting a connection, no addresses available for connection, and name resolution has completed, an exception will still be raised as before. Additionally, the following minor fixes have been made: - Refactor: Remove unnecessary members
shioimm
added a commit
that referenced
this pull request
Nov 30, 2024
… connection failure (#12223) * Improve the conditions for clearing the Connection Attempt Delay upon connection failure This change addresses a case that was overlooked in #12087. In the previous change, the Connection Attempt Delay was cleared at the point of a connection failure only if both of the following conditions were met: - No other sockets were attempting a connection - There were addresses still available to start a new connection In this update, the second condition has been removed. As a result, if name resolution succeeds after a connection failure and new addresses are obtained, it will be able to immediately attempt a connection to one of them. If there are no sockets attempting a connection, no addresses available for connection, and name resolution has completed, an exception will still be raised as before. --- Additionally, the following minor fixes have been made: * Refactor: Remove unnecessary members
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.
Reset Connection Attempt Delay when connection fails and there is no other socket connection in progress.
This is intended to resolve an issue that was temporarily worked around in Pull Request #12062.
TCPServer::new(used in tests such asTestNetHTTP_v1_2_chunked#test_timeout_during_non_chunked_streamed_HTTP_session_write) can only connect over either IPv6 or IPv4, depending on the environment.Since HEv2 attempts to connect over IPv6 first, environments where IPv6 connections are unavailable return ECONNREFUSED immediately.
In such cases, the client should immediately retry the connection over IPv4.
However, HEv2 includes a specification for a "Connection Attempt Delay," where it waits 250ms after the previous connection attempt before starting the next one.
This delay causes Net::OpenTimeout (100ms) to be exceeded while waiting for the next connection attempt to start.
With this change, when a connection attempt fails, if there are sockets still attempting to connect and there are addresses yet to be tried, the Connection Attempt Delay will be resetted, allowing the next connection attempt to start immediately.
Additionally, the following minor fixes have been made:
nfdsvalue used for select(2) is now reset with each wait.