关于ECONNRESET的问题处理

有几次我的andorid客户端报错：IOException:java.net.SocketException: recvfrom failed: ECONNRESET (Connection reset by peer)

寻找解决方案，android相关原因：

ok, the answer was that it's the server's fault - it had to close the connection after each request .

it might be that android keeps a pool of connections and use the old one or something like that .

anyway , now it works.

EDIT: according to the API of HttpURLConnection , this can be solved on the client side too:

Performance

The input and output streams returned by this class are not buffered. Most callers should wrap the returned streams with BufferedInputStream or BufferedOutputStream. Callers that do only bulk reads or writes may omit buffering.

When transferring large amounts of data to or from a server, use streams to limit how much data is in memory at once. Unless you need the entire body to be in memory at once, process it as a stream (rather than storing the complete body as a single byte array or string).

To reduce latency, this class may reuse the same underlying Socket for multiple request/response pairs. As a result, HTTP connections may be held open longer than necessary. Calls to disconnect() may return the socket to a pool of connected sockets. This behavior can be disabled by setting the http.keepAlive system property to false before issuing any HTTP requests. The http.maxConnections property may be used to control how many idle connections to each server will be held.

By default, this implementation of HttpURLConnection requests that servers use gzip compression. Since getContentLength() returns the number of bytes transmitted, you cannot use that method to predict how many bytes can be read from getInputStream(). Instead, read that stream until it is exhausted: when read() returns -1. Gzip compression can be disabled by setting the acceptable encodings in the request header:

   urlConnection.setRequestProperty("Accept-Encoding", "identity"); 

taken from: http//developer.android.com/reference/java/net/HttpURLConnection.html

有人提出解决方案：

你看 to reduce latency,this class may reuse the same underlying Socket for.......懂了吧 ，我们访问频率又不大，果断关掉。System.setProperty("http.keepAlive", "false");

System.setProperty("http.keepAlive", "false"); 

如果还是有问题，参考：

the answer was that it's the server's fault - it had to close the connection after each request . it might be that android keeps a pool of connections and use the old one or something like that–Jitesh Upadhyay

精简的原因分析：

java.net.SocketException: （Connection reset或者Connect reset by peer:Socket write error）。该异常在客户端和服务器端均有可能发生，引起该异常的原因有两个，第一个就是如果一端的Socket被关闭（或主动关闭或者因为异常退出而引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常(Connect reset by peer)。另一个是一端退出，但退出时并未关闭该连接，另一端如果在从连接中读数据则抛出该异常（Connection reset）。简单的说就是在连接断开后的读和写操作引起的。

大神总结如下：

1.你的socket队列中没有空间了
2.receiver never acknowledges data sent on a datastream socket(接受者不承认在数据流接口上发送的数据)
3.A connection will timeout if the local system doesn't receive an (ACK)nowledgement for data sent

Connection reset by peer
抛出的异常也有可能是客户端中断连接。 当客户端中断连接的时候服务器也会抛出这个异常出来。

就是说客户端正在连接的时候 突然终止 了连接，这样，服务器端会抛出Connection reset by peer 异常出来

http://topic.csdn.net/u/20080402/16/7fe0a9c2-cef5-4756-8c45-157555cd0097.html

第 4个异常是java.net.SocketException: （Connection reset或者 Connect reset by peer:Socket write error）。该异常在客户端和服务器端均有可能发生，引起该异常的原因有两个，第一个就是如果一端的Socket被关闭（或主动关闭或者因为异常退出而 引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常 (Connect reset by peer)。另一个是一端退出，但退出时并未关闭该连接，另一端如果在从连接中读数据则抛出该异常（Connection reset）。简单的说就是在连接断开后的读和写操作引起的。



http://topic.csdn.net/u/20080328/10/e08d894a-319a-4985-8407-50e103305e6c.html



我这里有关于网络异常方面的建议，发上去大家学习：
第 1个异常是java.net.BindException:Address already in use: JVM_Bind。该异常发生在服务器端进行new ServerSocket(port)（port是一个0，65536的整型值）操作时。异常的原因是以为与port一样的一个端口已经被启动，并进行监 听。此时用netstat –an命令，可以看到一个Listending状态的端口。只需要找一个没有被占用的端口就能解决这个问题。


第 2个异常是java.net.ConnectException: Connection refused: connect。该异常发生在客户端进行 new Socket(ip, port)操作时，该异常发生的原因是或者具有ip地址的机器不能找到（也就是说从当前机器不存在到指定ip路由），或者是该ip存在，但找不到指定的端 口进行监听。出现该问题，首先检查客户端的ip和port是否写错了，如果正确则从客户端ping一下服务器看是否能 ping通，如果能ping通（服务服务器端把ping禁掉则需要另外的办法），则看在服务器端的监听指定端口的程序是否启动，这个肯定能解决这个问题。


第3个异常是java.net.SocketException: Socket is closed，该异常在客户端和服务器均可能发生。异常的原因是己方主动关闭了连接后（调用了Socket的close方法）再对网络连接进行读写操作。


第 4个异常是java.net.SocketException: （Connection reset或者 Connect reset by peer:Socket write error）。该异常在客户端和服务器端均有可能发生，引起该异常的原因有两个，第一个就是如果一端的Socket被关闭（或主动关闭或者因为异常退出而 引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常 (Connect reset by peer)。另一个是一端退出，但退出时并未关闭该连接，另一端如果在从连接中读数据则抛出该异常（Connection reset）。简单的说就是在连接断开后的读和写操作引起的。


第5个异常是 java.net.SocketException: Broken pipe。该异常在客户端和服务器均有可能发生。在第4个异常的第一种情况中（也就是抛出SocketExcepton:Connect reset by peer:Socket write error后），如果再继续写数据则抛出该异常。前两个异常的解决方法是首先确保程序退出前关闭所有的网络连接，其次是要检测对方的关闭连接操作，发现对 方关闭连接后自己也要关闭该连接。

客户端错误代码10053 Software caused connection abort（软件原因导致连接中断）



又涉及到一个问题就是阻塞函数和非阻塞函数，阻塞Socket和非阻塞Socket

一 是阻塞函数，一是非阻塞函数。所谓阻塞函数，是指其完成指定的任务之前不允许程序调用另一个函数，在Windows下还会阻塞本线程消息的发送。所谓非阻 塞函数，是指操作启动之后，如果可以立即得到结果就返回结果，否则返回表示结果需要等待的错误信息，不等待任务完成函数就返回

http://www.aka.org.cn/Lectures/002/Lecture-2.1.8/Lecture-2.1.8/new_page_15.htm

http://www.cppblog.com/kenlistian/archive/2007/12/27/39746.html

http://hi.baidu.com/evenque/blog/item/1ccfc63ffc3527c17d1e7188.html

http://www.cic.tsinghua.edu.cn/jdx/lunwen/WinSockx.htm



Connection reset by peer的原因：
经常出现的Connection reset by peer: 原因可能是多方面的，不过更常见的原因是：
①：服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；
②：客户关掉了浏览器，而服务器还在给客户端发送数据；
③：浏览器端按了Stop
很多人都说是客户端造成的，没有办法控制，是个比较郁闷的问题。



引起该问题的原因是由于此时Server端连接已经被复位，而Client依然通过该连接在接收和发送数据，在网上搜索了一下该错误，发现该错误引起的原因大都是防火墙的原因，嘿嘿，又学了一招。



socket, nio socket 及nio socket框架MINA总结

Windows Sockets Error Codes

http://msdn2.microsoft.com/en-us/library/ms740668.aspx


socket 通信有通信的规则, 如果你希望保持长连接, 就应该有个通信协议, 包括写入/0也是规则的一部分, 传完一个文件等待下一个. 要可不保持长连接, 可使用webservice, 这样你的协议变的更为可读, 更容易包装成产品.

看你的程序希望read结束, 不象是希望保持长连接的样子, 晕ing



经常出现的Connection reset by peer: 原因可能是多方面的，不过更常见的原因是：
①：服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；
②：客户关掉了浏览器，而服务器还在给客户端发送数据；
③：浏览器端按了Stop
很多人都说是客户端造成的，没有办法控制，是个比较郁闷的问题。



这是网络连接断掉引起的，一般是由于通过了防火墙，而防火墙一般都会有超时的机制，在网络连接长时间不传输数据时，会切断这个TCP的session，这时就会导致Connection reset by peer error




http://topic.csdn.net/t/20060915/12/5024325.html



沟通非阻塞IO与阻塞IO - 输入流

沟通非阻塞IO与阻塞IO - 输出流

附加该问题的最近结论
1.我使用MyEclipse单步调试，当调试到inputStream 的时候，看变量，发现一个问题,
那就是SocketInputStream的Channel是null,为什么那，我不知道

又在网络上找到几句话粘贴到这里吧！如下

"No buffer space available , recv failed"

谢谢sandyen(杉叶)的回答，我在网上也搜到这个，但是不是这个原因。
问题已解决，确实不是程序的问题。
netstat -an发现有大量的端口占用，监听很多机器的139，445端口。
确定机器中了震荡波，下载补丁安装重启，问题解决。
导致这个异常的原因应该是系统的socket大量的资源被占用，
导致没有足够的资源接收前台上报或者回复的数据。