今天研究了一下 windows特有的 完成連接埠 IOCP 重疊IO連接埠 ,記錄下它與普通socket的區別

windows下的IOCP和 linux下的epoll(#epoll我還沒有研究過#) 都是屬於socket 網路編程的範疇.不過其特色是:用固定很少的線程去管理成千上萬個socket串連.

其相當於 非同步通訊 .普通socket是同步,同步 可能要一個線程一個socket連結 去做,由於系統可以啟動並執行線程數目有限,其就成為一個瓶頸了. IOCP/epoll 可以解決這個問題.

首先,你要懂得普通socket TCP的用法:

Serve端 WSAStartup,socket,bind listen,accept. accept之後就是阻塞的recv和send了.WSACleanup  .其中accept之後可以CreateThread 背景工作執行緒 來單獨處理recv和send.

client端 WSAStartup,socket,connect. connect之後就是阻塞的recv和send了.WSACleanup

而IOCP是這樣的:

Server端:

 1 WSAStartup 2 CreateIoCompletionPort建立完成連接埠 3 GetSystemInfo擷取CPU核心數目, 4 CreateThread建立CPU核心數目個背景工作執行緒,  5 WSASocket  ,  6 bind , 7 listen ,  8  // 一下都在迴圈內 9 WSAAccept  , 10 CreateIoCompletionPort 建立accept的SocketID與前面完成連接埠的綁定 , 11 WSARecv投遞操作(其實就是必須先接受一次資料,否則後面接受不到,不知道為什麼) ,12 //迴圈結束13 WSACleanup14 15 16 其中 背景工作執行緒 有不同的地方17 GetQueuedCompletionStatus 獲得資料,然後根據資料來決定 是WSARecv 還是 WSASend

其中 WSAAccept GetQueueCompletionStatus 是阻塞的,或者說是 事件驅動的,其會在那裡等待...

可以看到IOCP裡面用到了許多 WSA開頭的API,而其建立了多個背景工作執行緒,這就是線程池,但是你不用管理,GetQueueCompletionStatus會自動進行管理的.

IOCP與普通socket 兩個最重要的不同點 :

一個就是 GetQueueCompletionStatus ,這裡是阻塞的,根據接受的資料來WSARecv or WSASend.而普通的socket是直接在recv 和 send 阻塞的.IOCP 則不需要這樣.另一個就是前面的 WSAAccept ,這個接受到新的用戶端串連後,必須 先進行一次 WSARecv. 後續用戶端發送的資料 則是上面的GetQueueCompletionStatus 來做了.

IOCP是針對伺服器端的,對於用戶端,隨便,跟普通socket用戶端一樣.

 

 

附上我學習到的例子 非常的簡潔:

IOCP 簡單 命令列 樣本程式(伺服器和 6000socket連結 測試用戶端)

http://files.cnblogs.com/ayanmw/testiocp2.zip

 

在附上一篇文章,看完例子 自己理解下,再去看理論:

http://blog.csdn.net/piggyxp/article/details/6922277

其他 IOCP 完成連接埠 重疊IO的東西 自己搜尋吧.

IOCP模型分析：

http://linux.it219.com/archives/214

Windows IOCP模型與Linux EPOLL模組之比較:

http://blog.csdn.net/ljmwork/article/details/7871922

搜尋：iocp linux 獲得更多區別