套接字IO模型介紹

1、套接字I / O模型Wi n s o c k分別提供了“套接字模式”和“套接字I / O模型”，可對一個套接字上的I / O行為加以控制。套接字模式用于決定在隨一個套接字調用時，那些Wi n s o c k函數(shù)的行為。套接字模型描述了一個應用程序如何對套接字上進行的I / O進行管理及處理。“套接字I / O模型”與“套接字模式”是無關的。套接字模型的出現(xiàn)，正是為了解決套接字模式存在的某些限制。1Wi n s o c k提供的I / O模型s e l e c t（選擇）W S A A s y n c S e l e c t（異步選擇）W S A E v e n t S e l e c t（事件

2、選擇）Overlapped I/O（重疊式I / O）Completion port（完成端口）2操作系統(tǒng)對套接字I / O模型的支持情況3最通俗淺顯的“IO模式”解析老陳有一個在外地工作的女兒，不能經(jīng)常回來，老陳和她通過信件聯(lián)系。他們的信會被郵遞員投遞到他們的信箱里。 情況與Socket模型非常類似。 4select模型 老陳非常想看到女兒的信。以至于他每隔10分鐘就下樓檢查信箱，看是否有女兒的信，在這種情況下，“下樓檢查信箱”然后回到樓上耽誤了老陳太多的時間，以至于老陳無法做其他工作。 select模型和老陳的這種情況非常相似：周而復始地去檢查.如果有數(shù)據(jù).接收/發(fā)送. 5WSAAsync

3、Select模型 老陳使用了微軟公司的新式信箱。這種信箱非常先進，一旦信箱里有新的信件，蓋茨就會給老陳打電話：喂，大爺，你有新的信件了！從此，老陳再也不必頻繁上下樓檢查信箱了，牙也不疼了，你瞅準了，藍天.不是，微軟. WSAAsyncSelect模型是Windows下最簡單易用的一種SocketI/O模型。使用這種模型時，Windows會把網(wǎng)絡事件以消息的形式通知應用程序。 6應用程序可以對收到WM_SOCKET消息進行分析，判斷是哪一個socket產(chǎn)生了網(wǎng)絡事件以及事件類型 。7WSAEventSelect模型 微軟的信箱非常暢銷，購買微軟信箱的人以百萬計數(shù).以至于蓋茨每天24小時給客戶打電

4、話，累得腰酸背痛，喝蟻力神都不好使。微軟改進了他們的信箱：在客戶的家中添加一個附加裝置，這個裝置會監(jiān)視客戶的信箱，每當新的信件來臨，此裝置會發(fā)出“新信件到達”聲，提醒老陳去收信。蓋茨終于可以睡覺了。 8OverlappedI/O事件通知模型 微軟通過調查發(fā)現(xiàn)，老陳不喜歡上下樓收發(fā)信件，因為上下樓其實很浪費時間。于是微軟再次改進他們的信箱。新式的信箱采用了更為先進的技術，只要用戶告訴微軟自己的家在幾樓幾號，新式信箱會把信件直接傳送到用戶的家中，然后告訴用戶，你的信件已經(jīng)放到你的家中了！老陳很高興，因為他不必再親自收發(fā)信件了！ 9OverlappedI/O事件通知模型和WSAEventSelect

5、模型在實現(xiàn)上非常相似，主要區(qū)別在Overlapped”，Overlapped模型是讓應用程序使用重疊數(shù)據(jù)結構(WSAOVERLAPPED)，一次投遞一個或多個WinsockI/O請求。這些提交的請求完成后，應用程序會收到通知。什么意思呢？就是說，如果你想從socket上接收數(shù)據(jù)，只需要告訴系統(tǒng)，由系統(tǒng)為你接收數(shù)據(jù)，而你需要做的只是為系統(tǒng)提供一個緩沖區(qū) 10OverlappedI/O完成例程模型 老陳接收到新的信件后，一般的程序是：打開信封-掏出信紙-閱讀信件-回復信件.為了進一步減輕用戶負擔，微軟又開發(fā)了一種新的技術：用戶只要告訴微軟對信件的操作步驟，微軟信箱將按照這些步驟去處理信件，不再需要

6、用戶親自拆信/閱讀/回復了！老陳終于過上了小資生活！ 11OverlappedI/O完成例程要求用戶提供一個回調函數(shù)，發(fā)生新的網(wǎng)絡事件的時候系統(tǒng)將執(zhí)行這個函數(shù) 。12完成端口模型微軟信箱似乎很完美，老陳也很滿意。但是在一些大公司情況卻完全不同！這些大公司有數(shù)以萬計的信箱，每秒鐘都有數(shù)以百計的信件需要處理，以至于微軟信箱經(jīng)常因超負荷運轉而崩潰！需要重新啟動！微軟不得不使出殺手锏. 微軟給每個大公司派了一名名叫“CompletionPort”的超級機器人，讓這個機器人去處理那些信件！ 13“WindowsNT小組注意到這些應用程序的性能沒有預料的那么高。特別的，處理很多同時的客戶請求意味著很多線程并發(fā)地運行在系統(tǒng)中。因為所有這些線程都是可運行的沒有被掛起和等待發(fā)生什么事，Microsoft意識到NT內核花費了太多的時間來轉換運行線程的上下文Context，線程就沒有得到很多CPU時間來做它們的工作。大家可能也都感覺到并行模型的瓶頸在于它為每一個客戶請求都創(chuàng)建了一個新線程。創(chuàng)建線程比起創(chuàng)建進程開銷要小，但也遠不是沒有開銷的。14我們不妨設想一下：如果事先開好N個線程，讓它們在那hold堵塞，然后可以將所有用戶的請求都投遞到一個消息隊列中去。然后那N個線程