-
Notifications
You must be signed in to change notification settings - Fork 9.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Happy Eyeballs #506
Comments
+1. I recently misconfigured my router to a bad IPv6 setting and half my apps were failing but chrome and others would still work. Took me a couple days to figure out what was going wrong. |
This introduces a `ConnectionStrategy` interface for creating connections to a `Route`. The default `SimpleConnectionStrategy` implemention preserves the old behavior, passing hostnames down to the java.net stack which will (arbitrarily) chose one of the underlying IPs. The `ParallelConnectionStrategy` implementation will initiate a TCP handshake to each IP concurrently. I tested `ParallelConnectionStrategy` with our API endpoint and got the datacenter I'm close to, as expected, and the time it look was comparable to my RTT to that datacenter (5-10ms in most cases). Somewhat related to issue #506 (Happy Eyeballs).
This introduces a `ConnectionStrategy` interface for creating connections to a `Route`. The default `SimpleConnectionStrategy` implemention preserves the old behavior, passing along hostnames to Socket which will chose one of the underlying IPs. The `ParallelConnectionStrategy` implementation will initiate a TCP handshake to each IP concurrently and return the first connection to complete. I tested `ParallelConnectionStrategy` with our API endpoint and got the datacenter I'm close to, as expected, and the time it look was comparable to my RTT to that datacenter (5-15ms in most cases). Somewhat related to issue #506 (Happy Eyeballs).
This introduces a `ConnectionStrategy` interface for creating connections to a `Route`. The default `SimpleConnectionStrategy` implemention preserves the old behavior, passing along hostnames to Socket which will chose one of the underlying IPs. The `ParallelConnectionStrategy` implementation will initiate a TCP handshake to each IP concurrently and return the first connection to complete. I tested `ParallelConnectionStrategy` with our API endpoint and got the datacenter I'm close to, as expected, and the time it look was comparable to my RTT to that datacenter (5-15ms in most cases). Somewhat related to issue #506 (Happy Eyeballs).
@dlubarov , @JakeWharton do you folks happen to be working on bringing Happy Eyeballs support to OkHttp? There are more DHCPv6-based IPv6 networks every day, especially in corporate settings, and the ability to pick the better transport in parallel will greatly benefit user experience. |
It’s possible to implement this manually by making two HTTP requests yourself and picking the one that returns first. Doing it inside of OkHttp is more difficult. For example, what should the interceptors see? We might be able to do further work later to unblock this, but for now it seems very difficult to do well. |
So this is causing issues for IPv6 http requests with React Native, linked above. It sounds like the workaround suggested above is to do two requests in the above layer, with one forced to IPv4. Curious, how does one force IPv4 in an okhttp request? Do I need to resolve the DNS to the IPv4 and IPv6 address and add in Host headers manually? Or is there some easier way? |
Implement the Dns interface and strip the addresses you don't want. Be careful to not return an empty list; that case needs to throw an exception. |
Hey guys, by any chance you still planing on doing that? I'm facing the same problem here and the workaround doesn't really look good. It would be great to have a more sophisticated approach built-in the lib. |
Linking directly to RFC - https://tools.ietf.org/html/rfc8305 |
So, what is the plan? Will okhttp support Happy Eyeballs ? |
In the docs, I read:
However, when I run this code in an API 21 (5.0) emulator... public class MainActivity extends AppCompatActivity {
@SuppressLint("StaticFieldLeak")
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new AsyncTask<Void, Void, Void>() {
@Override
protected Void doInBackground(Void... voids) {
OkHttpClient client = new OkHttpClient();
String url = "https://directory.spaceapi.io/";
Request request = new Request.Builder().url(url).build();
try (Response response = client.newCall(request).execute()) {
Log.i("MainActivity", "Body: " + response.body().string());
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
}.execute();
}
} ...it fails with the following exception:
That host (directory.spaceapi.io) is accessible both via IPv4 and IPv6. However, the emulator only has link-local and site-local IPv6 addresses.
Am I right when I assume that this connection failure is due to the missing happy eyeballs implementation? |
Does that host work from chrome on the same mobile? |
Hmm, good question. From the built-in emulator browser I get a Edit: According to the Qualys SSL Labs client test, the client does support TLS 1.2. Then I assume the ciphersuites on the server are not yet supported by this device. |
I would suggest starting with a Stackoverflow question. That request works for me with a JDK OkHttp request. But I get an IPv4 address back. But debugging on this github issue is likely to spam 8 people. |
One thing to consider is whether we should add suppressed errors when we fail after multiple hosts. If we fail with IPv4 with a useful error but swallow it to deliver the IPv6 error then it's misleading. For discussion #5836 |
This is done. |
Awesome, thank you so much for this! I was wondering when a stable 5.0 release may be available. The milestone here doesn't help much (says past due by 1 year 🙂) |
If you're prepared to deal with small API changes between now and 5.0 final you can put it into production today. For OkHttp ‘alpha’ means ‘API instability’ but the code is extremely stable. |
I'd echo that but also say that feedback on this will probably help build confidence in OkHttp 5 and this rather big change. Remember it needs an opt-in #506 (comment) |
Do we know when this feature will be out of alpha , so that we can start using them in production? |
It's marked "alpha", but according to Reddit, it's good enough for production. |
When will this be moved to production from alpha ? |
It's a way off, we have some API changes (more KMP, not affecting existing 4.x APIs) we need to make. I can't give a date. But it's production ready, just not API stable |
Is happy eyeball also supported for web-socket initial connection? |
Yes. |
it support now? |
@MichaelJokAr looks like 5.x is still in alpha :( |
http://en.wikipedia.org/wiki/Happy_Eyeballs
The text was updated successfully, but these errors were encountered: