因為這個問題，我很想抽微軟。網上其他人有類似的問題，我也碰到了，沒有很好的解決方案。這個問題是Winsock所特有的（最起碼所有的問題都是在Windows平臺下）。一般在使用UDP Socket時，我們發出去數據，是不管它到不到達的，而且UDP并不是面向連接的，所以在收到這個錯誤時，會感覺很奇怪：“連接被重置10054”。

這個錯誤一般是使用UDP Socket接受時收到（這里我不講具體的語言了，不管你用C#、Python還是C，在Windows下都會有類似的問題，只要你調用類似ReceiveFrom函數）。這是上一次Send操作向一個地址發送，但是那個地址沒有Socket監聽（例如對等體崩潰），那么ICMP控制協議會向我們發送一個Port Unreachable錯誤，當然這個錯誤應該包含對方的詳細地址等信息，但是Winsock把這個錯誤轉化為Connection Reset，在你下一次調用讀操作的時候，引發異常，卻沒把詳細信息給你——例如用C#接受到的對方地址是0.0.0.0。

而這個問題最要命的是，如果你不采取措施，每次調用讀操作都會引發該異常！唯一恢復正常的辦法就是把Socket關掉，重開。這就非常要命：你要實現一個UDP服務器，把收到的音頻發給所有的客戶，如果某個客戶崩潰了或者網絡不好，你的Send不會出問題，但是你Receive的時候卻出了問題！好吧，你捕獲了異常，重新Receive，還是異常！好吧，你關掉Socket重新建立，但是因為不知道是哪個客戶出了問題，所以不能及時把他的地址從發送列表里去除（即使使用心跳檢測也要等幾秒種），下次Send還是這樣，你就不停地關閉創建Socket，誰受的了？

網絡上的討論，最后要么說這是一個bug，要么使用如下代碼（以C#為例）

const int SIP_UDP_CONNRESET=-1744830452;
socket.IOControl(SIP_UDP_CONNRESET, new byte[] {0, 0, 0, 0}, null);

設置這個選項忽略那個Reset錯誤，這樣不用重建Socket，只不過每次Socket都會向一些已經關閉的客戶發包，浪費了服務器資源；只能通過其他機制確定客戶端已經斷開，延遲一段時間后才能確定哪個客戶端出問題。

我想跟微軟說的是，你丫要不就在出問題的地方拋出異常，不然的話把詳細錯誤給了也行，再不行不要強制出一個錯誤整個Socket就毀了，結果一個都沒做到，默認的行為不是正常的UDP行為，還改錯誤類型，真是欠抽！