Home > Android, Bugs, Java, Networking > Java On Android TCP Socket Issue

Java On Android TCP Socket Issue

Related to my previous post [1] involving a project using Java sockets, I’d like to post about an issue I encountered while debugging the project. Allow me to first describe the environment and set up.

The Java side as an extended version of the class described in the linked post ran as client on Android, specifically a Galaxy Nexus device running Android 4.2.2 and later 4.3. Its goal was to send locally collected arrays of bytes via the socket to the server after connecting. The server was written in C++ with part of the networking side handled by the Qt framework (QTcpServer) and the actual communication via native sockets on a Windows 7 Ultimate x64 system.

The problem occurred upon the connecting of the Android client to the server: the connecting would be handled fine, the thread to handle the native socket initialized and started as it should be. After that however the issue was that never any data would be received on the server-side of the client socket. Checks using select() showed that there never arrived any data in the buffer. Upon verification with a telnet client (Putty) it turned out that the server was able to receive data just fine, and thus that the issue had to lie with the client side, i.e. the Android client.

Inspection using the Wireshark network traffic sniffer during the communication between the Android client and the server showed a normal TCP sequence, with SYN, SYN-ACK and ACK packets followed by a PSH-ACK from the client with the first data. This followed by an ACK from the server, indicating that the server network stack had at least acknowledged the data package. Everything seemed in order, although it was somewhat remarkable that the first client-side ACK had the exact same timestamp in Wireshark as the PSH-ACK packet.

Mystified, I stumbled over a few posts [2][3] on StackOverflow in which it was suggested that using Thread.sleep() after the connecting phase would resolve this. Trying this solution with a 500 ms sleep period I found that suddenly the client-server communication went flawlessly. My only question hereby is why this is the case.

Looking through the TCP specifications I didn’t find anything definite, even though the evidence so far suggests that the ACK on SYN-ACK can not be accompanied by a PSH or similar at the same time. Possibly that something else plays a role here, but it seems that the lesson here is that in case of non-functioning Java sockets one just has to wait a little while before starting to send data. I’d gladly welcome further clarification on why this happens.

Maya

[1] https://mayaposch.wordpress.com/2013/07/26/binary-network-protocol-implementation-in-java-using-byte-arrays/
[2] http://stackoverflow.com/questions/5326652/java-socket-read-not-receiving-write-sent-immediatly-after-connection-is-establi
[3] http://stackoverflow.com/questions/17073045/why-does-java-send-needs-thread-sleep

Advertisements
  1. July 10, 2014 at 3:12 AM

    I’m having a similar but different strange behaviour. I’m programming in C++ using the NDK and the Android application is acting as a client connecting to a server. I see a TCP SYN, SYN/ACK, ACK exchange then the android device issues a FIN immediately after the connection is ACKed open. Yet, I don’t close the socket. There’s no exception packet on the wire. I don’t even try sending data on the socket. It’s just closed by the Android device itself for no explainable reason. Even stranger if I do a poll(…) on the socket I receive pollfd.revents with 0x110 which is not legal (POLLHUP | POLLWRNORM). This means the socket is disconnected and write ready simultaneously, and that’s not a legal combination according to the linux docs (which android is based). This is using a well tested piece of code to do sockets but only this behaviour exists on android devices. Mac, iOS, and even Windows are all fine. This is very odd behaviour indeed!

  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: