剛要下班，運維部門的同事打電話來說，一個廣告服務器(UDP服務器)不接收數據了。我跑到他們部門一看，果然。界面上顯示接收數據包數量和速度都沒有變化了。據他們介紹，以前一直不出這個問題，但現在特別頻繁。一般運行10多分鐘可能就出問題了。
好事啊，出現故障的頻率這麼高，找到問題就很easy了。
我申請好權限，登錄到服務器上去觀察。
是什麼原因使服務器不接收數據包了呢？
1.服務器收到的包太多，把底層網絡堵塞了？
這種情況在流量上表現應該是下載流量一路上升，到最高點後，突然直線下降，甚至沒下載流量了。
可是觀看流量監控後，沒這種症狀。而且運維部的同事說，廣告服務器上的流量並不大。
那就不是這個問題了。至少可以先放一邊。
2.死鎖？
如果接收和處理消息的線程死鎖，會接收不到數據的。
但是界面還能動，最主要的是點擊界面上的“停止服務”按鈕，再開啓服務時，它又可以接收數據了。
肯定不是死鎖了
3.那就是接收消息的線程不工作了
怎麼證明呢？
還好，這個廣告服務器是一個UDP服務器，只有一個端口來接收和發送數據
上傳一個PE，用它觀察了服務器進程的網絡信息，發現已經沒有UDP服務了，就是 UDP socket被closesocket了。
當我停止服務，再開啓服務（進程沒退出）時，又看到UDP服務在運行了。
肯定是接收消息的線程循環裏處理錯誤不當，退出了線程。
看了代碼後，發現廣告服務器是用以前同事寫的一個簡單UDP框架來處理數據包的。而且發生錯誤後，只處理了10054這個錯誤，其他的錯誤發生時，就退出了消息循環。那要是如果有人破壞或客戶端代碼的bug，發送了一個比較大的udp數據包，就會發生錯誤，得到WSAEMSGSIZE錯誤代碼。。。
這樣服務器就罷工了。。。
爲了驗證我的猜想。我在接收和處理消息循環的工作線程中，可能退出的地方都寫上了日誌。然後放到服務器上去。
可是鬱悶的是不接收數據包的症狀不發生了，都過了幾個小時了。。。
沒法，就放着運行吧。。。沒事就上去看看。。。。