這段時間，可以說，簡直吐血，開發兩套完成端口控件，TCPIOCP和UDPIOCP，網上有現成的代碼，唉，沒有！真正沒有水分的，確實沒有。

至於UDPIOCP更別提。

雖然測試的代碼比比皆是。其實啊，你要寫一個成型的UDP完成端口，這個難度怎生是一個慘字可以形容？

於是乎，我一向的習慣是，不管做啥，首先會通過網絡搜集各種資料信息，等到大腦有了基本印象，然後付諸行動。

咱是一個強迫癥類型的人，於是就是各種累！

搜啊搜啊，於是乎，腦子更加混亂了。看看——各種論調，幾乎都是圍繞如何創建一個類TCP類型的UDP系統。各種創建可靠傳輸的UDP服務器

腦子發脹吧，甚至有人噴，UDP服務器真是高效？？當然了，如果是創建哪種鏈接類型（仿TCP）的UDP服務器，不管你咋弄，效率未必比TCP來得高效。

昨晚，頭腦理了一下，突然發現一個杯具的問題——

好，咱點擊一下UDP客戶端，服務端沒有啟動的情況下，大家會發現一個最有趣的現象就是，客戶端自己在哪兒不斷地發送信息包，發啊發啊發啊...........................

是不是挺過癮的？

這其實就是UDP它本身的特性：

不需要鏈接，有需求，直接發包，沒有需求，不占用系統資源 。

再來看看UDP服務端：

有信息發送過來，那麽就接收，沒有就等待

在此之前，咱維護一個鏈接客戶端對象管理池。在某個時候，咱把這個客戶端對象踢出去，但是在下一刻，這個被踢掉的客戶端發送信息過來了，於是乎，服務端繼續把這個客戶端當作新的鏈接對象進行接收數據。也就是說，服務端完全不需要也很難去分辨這個客戶端是不是被踢掉的客戶端。

也就是說，服務端的作用僅僅也僅僅響應消息的接收和發送，它不需要固定的鏈接。

這就是UDP這種協議本身的特性。

對，其實啊，很多人都走偏了。非要搞一個高仿的類TCP的UDP出來，其實都沒有靜下心來看看UDP其本身的特性。

回歸UDP，回歸UDP，回歸UDP，回歸UDP，回歸UDP，回歸UDP，回歸UDP，回歸UDP.........................................

哈，就那樣，所有的問題，一下子完全清晰了起來，看，所有問題完全解決了。

各種超時重傳，服務端為什麽要重傳？超過一定時限，釋放客戶端對象（沒有真正釋放，只是重置一下各參數），納入空閑管理——這些不多說，說太多了。

對吧，服務端為什麽要重傳？？為什麽呢？

作為數據需求的發送者 ，客戶端難道自己不做超時檢測，在一定時間內，沒有需要的消息到達，難道不重發需求？這是它本來的定位職責。

一旦客戶端退出，那麽退出就退出吧，服務端還要管你這個啊？不是笑話？

說到這裏，其實應用層要做的不多，也不復雜了。

數據包序列發送，客戶端返回包頭序列號，這中間都有可能會發生掉包情況，就看兩者的對比機制。

剩下來都是處理這方面的邏輯，方法多種，只要能夠保證數據包能夠完整地接收就行，不必啥可靠不可靠，只要信息最終能夠到達。

當你扔掉那些沈重 的負擔，你會發現，UDP就是那麽牛逼，UDPIOCP完成端口就是那麽牛逼！

最後，回歸UDP，回歸UDP，回歸UDP，回歸UDP，回歸UDP，回歸UDP，回歸UDP，回歸UDP.........................................

高效的UDPIOCP完成端口——啥叫做高效？？