Develop Reference

"java.net.SocketException: Software caused connection abort" For no particular reason 30 seconds after socket connection [duplicate]

This question already has answers here:
Official reasons for "Software caused connection abort: socket write error"
(14 answers)
Closed 3 years ago.
I am facing a strange issue with Android's airplane mode and a Socket exception 30 seconds after opening a new Socket connection.
Here's what I do on my app that creates an issue:
Have an opened Socket connection and turn on and off airplane mode.
Reopen a new Socket connection with the server.
Wait 30 seconds and get a java.net.SocketException: Software caused connection abort on a DataInputStream readByte() call.
I have checked my server logs and the server is not disconnecting the client.
Does anyone know what could cause this? I've browsed other posts with the same exception, but they all had a more detailed error message. I can also send and receive messages with that Socket connection fine for 30 seconds, but then it randomly throws an exception.

i think to mange this case , opening airplane mode and turning of you should make listener
for internet connection and when internet state change to there is connection rebuild your socket and when state changed to no internet close the socket
you CAN find an example on Internet connectivity change listener here

Nearby Connections 2.0: Both sides request connections, but don't successfully connect

I'm trying to use the new Android Nearby Connections v2.0 API with the P2P_CLUSTER connection strategy. The following problem (in which both devices request connections, but don't successfully connect) seems to occur on a variety of devices running Android K-N. Sometimes the code gets a successful persistent connection... Sometimes it doesn't.
In this scenario, both sides are advertising and discovering, both sides discover each other, and both sides send connection requests (but connection is not initiated). It's difficult to make this situation happen reliably with a specific test case, but it does happen.
Using Android Monitor, I've captured detailed information about what this scenario looks like from one side, and listed the sequence of events below. In this particular session, the device that I was monitoring was a very cheap KitKat phone, and the remote endpoint was a Samsung Lollipop tablet (in case that's relevant).
The remote node is discovered, and we issue requestConnection
Immediately afterward, Android Monitor shows this error:
09-28 11:49:38.706 17321-17823/? E/NearbyConnections: In startClient(), UKEY2 failed with endpoint AqXW
java.io.IOException: bt socket closed, read return: -1
at android.bluetooth.BluetoothSocket.read(BluetoothSocket.java:647)
at android.bluetooth.BluetoothInputStream.read(BluetoothInputStream.java:96)
at java.io.InputStream.read(InputStream.java:162)
at java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:149)
at java.io.BufferedInputStream.read(BufferedInputStream.java:295)
at libcore.io.Streams.readFully(Streams.java:81)
at java.io.DataInputStream.readInt(DataInputStream.java:103)
at xkj.c(:com.google.android.gms#11509230:1)
at xkg.run(:com.google.android.gms#11509230:8)
at mng.run(:com.google.android.gms#11509230:25)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at mso.run(:com.google.android.gms#11509230)
at java.lang.Thread.run(Thread.java:818)
Immediately after that, it hits the requestConnection's ResultCallback, with STATUS_ENDPOINT_IO_ERROR (8012).
Next, because the requestConnection returned an error, we stop discovery, wait 3 seconds, and then start discovery again.
The next trace message after we restart discovery is this one from NearbyConnections:
09-28 11:49:46.333 17321-17412/? E/NearbyConnections: onIncomingConnection() for client 308946494 failed to initialize the connection with IkFxWFf_F-sAAAAAAAAAHHA_I2pIK25WaixTQEZSNHtVbmtub3duIFVzZXI
java.io.IOException: Failed to read ConnectionRequestFrame
at xjj.a(:com.google.android.gms#11509230:61)
at xlr.run(:com.google.android.gms#11509230:12)
at mng.run(:com.google.android.gms#11509230:25)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at mso.run(:com.google.android.gms#11509230)
at java.lang.Thread.run(Thread.java:818)
Caused by: java.io.IOException: bt socket closed, read return: -1
at android.bluetooth.BluetoothSocket.read(BluetoothSocket.java:647)
at android.bluetooth.BluetoothInputStream.read(BluetoothInputStream.java:96)
at java.io.InputStream.read(InputStream.java:162)
at java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:149)
at java.io.BufferedInputStream.read(BufferedInputStream.java:295)
at libcore.io.Streams.readFully(Streams.java:81)
at java.io.DataInputStream.readInt(DataInputStream.java:103)
at xkj.c(:com.google.android.gms#11509230:1)
at xjj.a(:com.google.android.gms#11509230:56)
at xlr.run(:com.google.android.gms#11509230:12) 
at mng.run(:com.google.android.gms#11509230:25) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) 
at mso.run(:com.google.android.gms#11509230) 
at java.lang.Thread.run(Thread.java:818)
I'm guessing that the above error was triggered from a requestConnection from the other side? And if we hadn't had that error, it would have gone to my onConnectionInitiated callback? (Just to clarify: It did not hit my onConnectionInitiated callback.)
Next, I once again discover the other node, and requestConnection once more.
Immediately after this, I see the following (different) error message from NearbyConnections:
09-28 11:51:14.639 17321-17412/? E/NearbyConnections: sendConnectionRequest() for client 308946494 failed to initialize the connection with endpoint AqXW
xjx: In connectImpl(), failed to connect to Bluetooth device 28:BE:03:0C:F1:5B for endpoint AqXW
at xlo.a(:com.google.android.gms#11509230:126)
at xjs.run(:com.google.android.gms#11509230:12)
at mng.run(:com.google.android.gms#11509230:25)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at mso.run(:com.google.android.gms#11509230)
at java.lang.Thread.run(Thread.java:818)
Next, we hit the requestConnection's ResultCallback with STATUS_BLUETOOTH_ERROR (8007)
After this, I saw the devices connect then auto-disconnect, which repeated several times. They never did get a successful persistent connection, although I've seen this happen after a bunch of errors.

That's a simultaneous connection clash; if you have 2 devices connecting to each other at the same time, Nearby Connections will (randomly) fail one of the device's requestConnection()'s first before the second device triggers onConnectionInititated() on both devices. That's why you're seeing "java.io.IOException: bt socket closed, read return: -1" in the first log.
If it weren't for the STATUS_BLUETOOTH_ERROR failures, you should be seeing the two devices successfully connect.

Reconnection Error Stream Management Smack

i discovered a really big problem (probably mine?) about the XMPP reconnection process in smack library v4.1.5 (Android) and openfire v4.0.1.
I activated the stream management on the client in this way:
XMPPTCPConnection.setUseStreamManagementDefault(true);
XMPPTCPConnection.setUseStreamManagementResumptionDefault(true);
and activated the automatic reconnection in this way:
ReconnectionManager.getInstanceFor(this.xmppConnection).enableAutomaticReconnection();
After the first successfull connection and login, when the internet connection goes down and the reconnection process starts I get the following error:
W/AbstractXMPPConnection: Connection closed with error
org.jivesoftware.smack.XMPPException$StreamErrorException: conflict You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions
<stream:error><conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error>
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1003)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:944)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:959)
The reconnection manager connects and authenticates very well but then I receive the previous error!
I tried to change the resource also but nothing, it doesn't work!
Someone could help me in understanding what is wrong?

Connection closed with error?

Xmpp Connection with android, get exception after login, connection close with error , org.jivesoftware.smack.SmackException: Parser got END_DOCUMENT event. This could happen e.g. if the server closed the connection without sending a closing stream element,

Please set packet timeout
connection.setPacketReplyTimeout(10000)

Socket close timing

I have what appears to be a timing problem between a client (Galaxy Nexus) and a custom server since upgrading from Ice Cream Sandwich to Jelly Bean. Here is the general flow:
Client opens socket, issues HTTP get to server
Server accepts, starts new thread, responds with HTTP header and 200 OK.
Server writes (binary) file to socket.
Client reads data from socket and saves to a file.
After server thread writes all data, it closes the socket, and terminates
This has worked well over the past several months prior to the Jelly Bean update. Since the update the binary transfer succeeds about 70% of the time. The remaining 30% fails
when 'serverSocket.getInputStream().read' returns a -1 indicating the end of stream has been reached. No data has been read, no error exceptions raised, nothing in logcat.
The possibility of a timing problem arises when I change the server behavior in step #5. The thread was closing the socket after the write with the observed problems. If I remove the socket close, terminate the thread after the write, and let the OS eventually close the socket then it seems to work all the time.
I used tcpdump and WireShark to look at the packets in both the successful and failed cases. In the failed case a socket is closed in a few milli-seconds while in the successful case the socket is closed is a quarter or more of a second. The net of this is that any delay we cause in the socket closing improves our chances for success.
If anyone has any suggestions with what we may be doing to cause this problem or suggestions on how to narrow down the problem please feel free to respond. I can add code samples if required.

It looks like that when the server ask for the connection close, the socket is immediatly closed. Maybe the default ocket linger's time has changed between version ???
Try setting the socket linger's time using:
socket.setSoLinger(boolean on, int timeout);
to have the server waiting some time before close channel if some data still waiting to be sent.
If this doesn't solve, you can change your flow above to:
...
4.Client reads data from socket and saves to a file.
5.Client send confirmation to server.
6.Server close connection.
--EDITED--
A gracefull way to achive the above without additional TCP data packets traveling for the closing confirmation is:
when server finish writing to the socket calls:
socket.shutdownOutput();
when client socket.read() returns -1, client calls:
socket.close();
This ensures that client is informed that all data has been sent, and sender will wait for the socket closure protocol to complete.