quic: temporarily disable preferred address tests #33934
Closed
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
The way the preferred address mechanism is supposed to work is this: A server might be exposed via multiple network interfaces / addresses. The preferred address is the one that clients should use. If a client uses one of the non-preferred addresses to initially connect to the server, the server will include the preferred address in it's initial transport params back to the client over the original connection. The client then can make a choice: it can either choose to ignore the advertised preferred address and continue using the original, or it can transition the in-flight connection to the preferred address without having to restart the connection. In the latter case, the connection will start making use of the preferred address but it might not do so immediately. To test this mechanism properly, we should have our server configured on multiple endpoints with one of those marked as the preferred. The connection should start on one and preceed uninterrupted to completion. If the preferred address policy is "accept", the client will accept and transition to the servers preferred address transparently, without interupting the flow. The current test is deficient because the server is only listening on a single address which is also advertised as the preferred. While the client should get the advertisement, we're not actually making use of the preferred address advertisement and nothing on the connection changes The ipv6 version of the test is also hanging on some platforms and it's not entirely clear why yet.
jasnell
force-pushed
the
quic-disable-preferred-address-test
branch
from
214512d to
1a6c7d9
Compare
jasnell
added
the
quic
danbev
approved these changes
Jun 18, 2020
|
@nodejs/quic ... fast track? |
addaleax
approved these changes
Jun 19, 2020
jasnell
added
author ready
jasnell
added a commit
that referenced
this pull request
Jun 22, 2020
The way the preferred address mechanism is supposed to work is this: A server might be exposed via multiple network interfaces / addresses. The preferred address is the one that clients should use. If a client uses one of the non-preferred addresses to initially connect to the server, the server will include the preferred address in it's initial transport params back to the client over the original connection. The client then can make a choice: it can either choose to ignore the advertised preferred address and continue using the original, or it can transition the in-flight connection to the preferred address without having to restart the connection. In the latter case, the connection will start making use of the preferred address but it might not do so immediately. To test this mechanism properly, we should have our server configured on multiple endpoints with one of those marked as the preferred. The connection should start on one and preceed uninterrupted to completion. If the preferred address policy is "accept", the client will accept and transition to the servers preferred address transparently, without interupting the flow. The current test is deficient because the server is only listening on a single address which is also advertised as the preferred. While the client should get the advertisement, we're not actually making use of the preferred address advertisement and nothing on the connection changes The ipv6 version of the test is also hanging on some platforms and it's not entirely clear why yet. PR-URL: #33934 Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
|
Landed in 9f2e00f |
This was referenced Jun 23, 2020
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.
The way the preferred address mechanism is supposed to work
is this: A server might be exposed via multiple network
interfaces / addresses. The preferred address is the one that
clients should use. If a client uses one of the non-preferred
addresses to initially connect to the server, the server will
include the preferred address in it's initial transport params
back to the client over the original connection. The client
then can make a choice: it can either choose to ignore the
advertised preferred address and continue using the original,
or it can transition the in-flight connection to the preferred
address without having to restart the connection. In the latter
case, the connection will start making use of the preferred
address but it might not do so immediately.
To test this mechanism properly, we should have our server
configured on multiple endpoints with one of those marked
as the preferred. The connection should start on one and preceed
uninterrupted to completion. If the preferred address policy
is "accept", the client will accept and transition to the servers
preferred address transparently, without interupting the flow.
The current test is deficient because the server is only listening
on a single address which is also advertised as the preferred.
While the client should get the advertisement, we're not actually
making use of the preferred address advertisement and nothing on
the connection changes
The ipv6 version of the test is also hanging on some platforms and
it's not entirely clear why yet.
/cc @nodejs/quic
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes