UdpVehicleService stops responding after a few seconds on certain phones.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use a phone running Cyanogen Android 2.3.4 or previous.
2. Start AirboatServer on phone.
3. Connect using BoatDebugger or BoatConfig.

What is the expected output? What do you see instead?

The connection panel initially flashes green, but quickly changes to red.  Data 
from the phone is displayed and up-to-date, but commands and function calls 
(e.g. sending waypoints, teleop commands) do not seem to be received.

Please use labels and text to provide additional information.

This was previously observed only on private networks (no Internet access) and 
on certain routers.  However, it has more recently been seen on CMU and Android 
hotspot networks, and on both Nexus S and Nexus One phones.

Original issue reported on code.google.com by psi...@gmail.com on 22 Nov 2011 at 4:02

[GoogleCodeExporter]

After some tracing, I found the problem in the UdpServer receive code.  When a 
UDP packet is received on certain phones, the following call seems to take a 
very long time (~120ms):

packet.getSocketAddress();

Oddly, on other phones, this call takes almost no time at all.

Original comment by psi...@gmail.com on 22 Nov 2011 at 4:03

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Ok, figured it out.  The problem is apparently a bug in the 
InetSocketAddress/InetAddress constructors.  When "new InetSocketAddress()" is 
called, it calls InetAddress.getHostname(), which triggers a reverse DNS lookup 
that takes a long time if there is no hostname.  On incoming UDP packets, this 
hostname is often unresolved, since the address in the packet is just numeric.  

See:
http://mailinglists.945824.n3.nabble.com/Android-and-reverse-DNS-lookup-issues-t
d3011461.html

I could add a hostname using InetAddress.getByAddress(String, byte[]), but 
there is a bug in this code where the hostname is not specified.  So instead I 
put in a workaround that uses reflection to directly manipulate the hostname, 
filling in a dummy string that prevents a reverse DNS call from happening.

See:
http://code.google.com/p/android/issues/detail?id=13117#c14

The issue should no longer occur after the patch in r572.

Original comment by psi...@gmail.com on 22 Nov 2011 at 4:09

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****