Connection reset by peer
web 程序的服務器段，在鏈接數據庫的時候被同一個“對等點”重置了。對等點重置的意思其實就是被同一個權限相同的管理員或者是程序給強制佔用了權限，好像目前 連接被斷了一樣，實際上這個時候連接並沒有斷開，是被“重置”了。就是能找到連接，但程序之間比較笨，自己找不到失去的那個連接了。
“連接被對等點（peer）重置”，這時，只要把防火牆關閉就好了。就是說暫時找不到那個以前的連接了，也許斷了，也許沒有斷，但就是找不到。
10053 您的主機中的軟件放棄了一個已建立的連接。
//////////////////////////////////////////////
一個以建立的連接被用戶的主機上的軟件終止，可能是因爲一次數據
傳輸超時或者是協議錯誤。還有就是不要再連接事件中發送消息
總結一下：
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://doc.codesky.net/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大量的資源被佔用， 導致沒有足夠的資源接收前臺上報或者回復的數據。 http://topic.csdn.net/t/20060315/11/4615627.html