Use IPv4 for Android connections

[emrekultursay]

Summary

When adb client connects to adb server, or when lldb connects to
lldb server on Android device, IPv6 does not work (at least on
Windows it does not work).

For Android on Windows, each IPv6 failure (fallback-to-IPv4) wastes
2 seconds, and since this is called 5 times when attaching, LLDB
is wasting 10 seconds. This CL brings a big improvement to attach latency.

[emrekultursay]

Update commit message.

[labath]

Getaddrinfo documentation says:

Normally,  the  application
should  try  using the addresses in the order in which they are returned.  The sorting function
used within getaddrinfo() is defined in RFC 3484; the order can be  tweaked  for  a  particular
system by editing /etc/gai.conf (available since glibc 2.5).

I don't like when apps question or try to override system settings. And preferring ipv4 seems rather backward-looking.

So, IIUC, the problem is that adb only listens on the ipv4 loopback address (and that windows takes 2 seconds to reject a loopback connection). Is that correct? Where do the addresses that we're connecting to come from (the user or lldb code)? If it's lldb code, maybe we could just replace the relevant "localhost" names with an explicit ipv4 loopback address?

Also, have you looked at the possibility of reducing the number of adb connections we make? My memory of adb is fairly hazy, but I do remember that some queries result in immediate connection termination. Still, five connections seems like too much...

[emrekultursay]

Enforce IPv4 usage only in Android code, revert non-Android changes.

[emrekultursay]

In D79757#2031186, @labath wrote:

...
Where do the addresses that we're connecting to come from (the user or lldb code)? If it's lldb code, maybe we could just replace the relevant "localhost" names with an explicit ipv4 loopback address?

This is great feedback, thank you! yes, it was just two places that had "localhost" hard-coded, and just by changing it to ipv4 loopback address, I achieved the same improvement. :)

[labath]

Cool. This looks good now.

As an aside, it would be nice if adb actually started supporting ipv6 -- it's over 20 years old now...

[clayborg]

nice catch!

[clayborg]

There was a patch previous to this that enabled IPv6. We need IPv6 on some computers here at Facebook. Can you check this file's log and look at the IPv6 patch and make sure this doesn't just undo that patch prior to committing this? If it does undo that patch, maybe we can check to see if IPv6 works somehow in LLDB one time and then enable IPv6 if it is supported and disable it if not?

[aadsm]

@clayborg the support we added was for the lldb-server.

[clayborg]

In D79757#2036618, @aadsm wrote:

@clayborg the support we added was for the lldb-server.

ok, phew!

[emrekultursay]

I admit I don't fully understand the details of that CL and how it may interact with this one. However, I can say that I verified this CL with an Android device connected over IPv6.

So, I think this CL is ready to be submitted. (I don't have commit access).

lldb/source/Host/common/TCPSocket.cpp

Status TCPSocket::Connect(llvm::StringRef name) {
   std::string host_str;
   std::string port_str;
   int32_t port = INT32_MIN;
   if (!DecodeHostAndPort(name, host_str, port_str, port, &error))
     return error;
 
   std::vector<SocketAddress> addresses = SocketAddress::GetAddressInfo(
       host_str.c_str(), nullptr, AF_UNSPEC, SOCK_STREAM, IPPROTO_TCP);
+  // IPv4 is more likely to succeed than IPv6. To avoid costly retries,
+  // we sort based on family to prioritize IPv4 over IPv6.
+  std::sort(addresses.begin(), addresses.end(),
+            [](SocketAddress a, SocketAddress b) {
+              return a.GetFamily() < b.GetFamily();
+            });
   for (SocketAddress &address : addresses) {
     error = CreateSocket(address.GetFamily());
     if (error.Fail())
       continue;
 
     address.SetPort(port);
 
     if (-1 == llvm::sys::RetryAfterSignal(-1, ::connect,