[HTTPCLIENT-2178] Implement Happy Eyeballs V2 (RFC 8305) #693
Conversation
|
@rschmitt Could you please take a look at this PR as you are the requester of this feature? |
…nous client connection operator with RFC 6724 address selection.
arturobernalg
force-pushed
the
happyEyeBalls2
branch
from
36d9269 to
16a9df9
Compare
|
This is still on my to-do list, I'll get to it when I can. |
There was a problem hiding this comment.
I think we should break this up into two or three smaller tasks.
- We already have connection initiation code that tries multiple IP addresses sequentially, and I think we should start by adding an option (maybe in
ConnectionConfig) that allows the async client to stagger those connection attempts instead. We could ship this disabled by default and then enable it later. - We can add a
DnsResolver(or similar) that implements RFC 6724 destination address selection rules. This could be done by wrapping a delegateDnsResolver - We can add a
ConnectionConfigto control protocol family preference, e.g.PREFER_IPV4,PREFER_IPV6,IPV4_ONLY,IPV6_ONLY, andINTERLEAVE.
The combination of staggered-concurrent connection attempts, destination address selection rules, and interleaved protocol families would give us basically all the MUSTs and SHOULDs in RFC 8305, but the functionality would be much better integrated into existing code and abstractions, and we could ship it in smaller increments.
| * | ||
| * @since 5.6 | ||
| */ | ||
| public final class AsyncClientHappyEyeballs { |
There was a problem hiding this comment.
Remember, I added a runner for these:
$ ./run-example.sh AsyncClientHappyEyeballs
Executing request GET http://ipv6-test.com/
GET http://ipv6-test.com/->HTTP/1.1 400 Bad Request
Executing request GET https://ipv6-test.com/
SimpleBody{content length=442, content type=text/html; charset=iso-8859-1}
GET https://ipv6-test.com/->HTTP/1.1 400 Bad Request
SimpleBody{content length=442, content type=text/html; charset=iso-8859-1}
Shutting down
The runner can pass in command line arguments, so it'd be nice if this class could take a URI as an argument, e.g.:
$ ./run-example.sh AsyncClientHappyEyeballs http://neverssl.com/
| new FutureCallback<SimpleHttpResponse>() { | ||
|
|
||
| @Override | ||
| public void completed(final SimpleHttpResponse response) { |
There was a problem hiding this comment.
Do we have access to the resolved IP address from here? It'd be nice to print that
| public final class HappyEyeballsV2AsyncClientConnectionOperator | ||
| implements AsyncClientConnectionOperator, ModalCloseable { |
There was a problem hiding this comment.
I think that AsyncClientConnectionOperator is too high-level for this. There's unrelated stuff in here like upgrade, for one thing. For another, there's an interface called ConnectionInitiator that seems like it would be a really good fit for an algorithm that implements staggered, concurrent, asynchronous connection establishment.
In fact, one thing we can consider is teaching the existing MultihomeConnectionInitiator/MultihomeIOSessionRequester to perform concurrent connection attempts, rather than sequential ones. That would provide the most important and most difficult part of RFC 8305, and it would work with any endpoint with multiple IP addresses, irrespective of IPv4/IPv6 configuration.
|
@ok2c What do you think of the idea of upgrading the existing |
@arturobernalg @rschmitt I am very much in favor of splitting the change-set into several smaller ones starting with |
|
all right @rschmitt .. i do the changes |
…e dialing). Add Rfc6724AddressSelectingDnsResolver; refactor MultihomeIOSessionRequester; wire via ConnectionConfig. New AsyncClientHappyEyeballs example (URI args, System.out trace) and JUnit tests; Java 8 compatible.
arturobernalg
force-pushed
the
happyEyeBalls2
branch
from
f8b92f3 to
44efeaa
Compare
|
@rschmitt please give another change to the PR |
This pull request introduces a minimal implementation of Happy Eyeballs Version 2 (RFC 8305) for the asynchronous client connection operator in Apache HttpComponents Client 5.x. It focuses on a simple, straightforward approach to dual-stack (IPv6/IPv4) address resolution and staggered connection attempts, while integrating a basic RFC 6724 address selection mechanism.
Key highlights:
Minimal RFC 6724 Support: Implements essential rules for address sorting (e.g., precedence, scope, label matching, longest prefix), with source address discovery via UDP probes. Non-critical rules (e.g., deprecated addresses, home addresses) are marked as TODO for future enhancements.
Staggered Connections: Uses a single-threaded ScheduledExecutorService for delaying connection attempts (default: 250ms), ensuring compliance with RFC 8305's latency minimization without unnecessary complexity.
Integration: Easily configurable via PoolingAsyncClientConnectionManagerBuilder.setConnectionOperator(). Includes shutdown methods for resource management.