Skip to content

Commit

Permalink
quic: temporarily disable preferred address tests
Browse files Browse the repository at this point in the history
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>
  • Loading branch information
jasnell committed Jun 22, 2020
1 parent 46ee864 commit 9f2e00f
Show file tree
Hide file tree
Showing 2 changed files with 81 additions and 20 deletions.
42 changes: 34 additions & 8 deletions test/sequential/test-quic-preferred-address-ipv6.js
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,38 @@ if (!common.hasQuic)
if (!common.hasIPv6)
common.skip('missing ipv6');

const Countdown = require('../common/countdown');
// TODO(@jasnell): Temporarily disabling the preferred address
// tests because we need to rethink through how exactly this
// mechanism should work and how we should test it.
//
// 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.
common.skip('preferred address test currently disabled');

const assert = require('assert');
const fixtures = require('../common/fixtures');
const key = fixtures.readKey('agent1-key.pem', 'binary');
Expand All @@ -25,12 +56,6 @@ const server = createQuicSocket({ endpoint: { type: 'udp6' } });

const kALPN = 'zzz'; // ALPN can be overriden to whatever we want

const countdown = new Countdown(1, () => {
debug('Countdown expired. Destroying sockets');
server.close();
client.close();
});

server.listen({ key, cert, ca, alpn: kALPN, preferredAddress: {
port: common.PORT,
address: '::',
Expand Down Expand Up @@ -87,7 +112,8 @@ server.on('ready', common.mustCall(() => {
stream.resume();

stream.on('close', common.mustCall(() => {
countdown.dec();
server.close();
client.close();
}));
}));

Expand Down
59 changes: 47 additions & 12 deletions test/sequential/test-quic-preferred-address.js
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,38 @@ const common = require('../common');
if (!common.hasQuic)
common.skip('missing quic');

const Countdown = require('../common/countdown');
// TODO(@jasnell): Temporarily disabling the preferred address
// tests because we need to rethink through how exactly this
// mechanism should work and how we should test it.
//
// 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.
common.skip('preferred address test currently disabled');

const assert = require('assert');
const fixtures = require('../common/fixtures');
const key = fixtures.readKey('agent1-key.pem', 'binary');
Expand All @@ -22,17 +53,19 @@ const server = createQuicSocket();

const kALPN = 'zzz'; // ALPN can be overriden to whatever we want

const countdown = new Countdown(1, () => {
debug('Countdown expired. Destroying sockets');
server.close();
client.close();
});

server.listen({ key, cert, ca, alpn: kALPN, preferredAddress: {
server.listen({
port: common.PORT,
address: '0.0.0.0',
type: 'udp4',
} });
key,
cert,
ca,
alpn: kALPN,
preferredAddress: {
port: common.PORT,
address: '0.0.0.0',
type: 'udp4',
}
});

server.on('session', common.mustCall((session) => {
debug('QuicServerSession Created');
Expand All @@ -59,14 +92,15 @@ server.on('ready', common.mustCall(() => {
cert,
ca,
alpn: kALPN,
preferredAddressPolicy: 'accept' } });
} });

client.on('close', common.mustCall());

const req = client.connect({
address: 'localhost',
port: endpoint.address.port,
servername: 'localhost',
preferredAddressPolicy: 'accept',
});

req.on('ready', common.mustCall(() => {
Expand All @@ -83,7 +117,8 @@ server.on('ready', common.mustCall(() => {
stream.resume();

stream.on('close', common.mustCall(() => {
countdown.dec();
server.close();
client.close();
}));
}));

Expand Down

0 comments on commit 9f2e00f

Please sign in to comment.