本周要進行boost asio庫的學習，在學習之前發現最好需要先瞭解一下前攝器模式，這樣對asio庫的理解很有幫助，故寫下此文 我之前寫的隨筆XShell的模擬實現中的鏈接方式可以說是同步的（伺服器阻塞等待鏈接），這樣當有伺服器端在等待鏈接的時候就浪費了大量的資源，我們可以讓伺服器非同步等待客戶端的鏈 ...
本周要進行boost asio庫的學習，在學習之前發現最好需要先瞭解一下前攝器模式，這樣對asio庫的理解很有幫助，故寫下此文
我之前寫的隨筆XShell的模擬實現中的鏈接方式可以說是同步的（伺服器阻塞等待鏈接），這樣當有伺服器端在等待鏈接的時候就浪費了大量的資源，我們可以讓伺服器非同步等待客戶端的鏈接，伺服器在等待鏈接的同時可以做別的事情，等到客戶端鏈接請求到來的時候，調用一個回調執行鏈接，這就很靈活。
先來一段關於前攝器模式的官話：前攝器模式支持多個事件處理器的多路分離和分派，這些處理器由非同步事件的完成來觸發。通過集成完成事件（completion event）的多路分離和相應的事件處理器的分派，該模式簡化了非同步應用的開發。
簡單點說，前攝器的實現多虧了多個事件處理器將事件和處理分離開，和處理方式的分派。而這些事件處理器的的觸發方式是當被非同步事件（僅限完成事件）通知而出發的。把這些個東西搞在一起就是前攝器模式了。
- 前攝器(proactor)模式
前攝器模式主要利用操作系統的非同步操作特性（如果操作系統不支持非同步的話前攝器模式就。。。），簡單的說，當你想到非同步的時候第一反應一般就是select，poll和epoll這幾個函數吧（或者是類似Qt的消息和槽函數之類的），當你的select函數捕捉到一個請求的時候，就執行一個操作（例如傳輸一個小視頻），不過這一般都是在編寫的應用程式中實現的，前攝器和這個方式不同的地方就是，它可以讓別人幫他乾搬磚的活，當瀏覽器請求一個文件，事件處理器就會把這個請求告訴操作系統，讓操作系統去辦，而事件處理器本身只關註操作系統發送回來的完成事件，事件處理器收到完成事件就拿操作系統搬好的磚，交給工頭，任務就算完成了。下麵對連接請求和文件請求兩個操作進行圖片詳解~
- web伺服器本身應該先開啟接受連接的操作，並且把非同步連接（就是說select函數你得寫好並且調用吧，不然怎麼接受連接請求）的操作准備好，以備客戶端（這裡就是瀏覽器啦）連接
- 和操作系統溝通，註冊相關函數（例如回調函數之類的）
- 為事件分離器註冊好回調函數
- 瀏覽器發送連接請求
- 這時候連接請求的數據實質上是由操作系統接收的（應用程式把最累的活丟給操作系統乾）
- 事件分離器本身只關註完成事件，儼然一副小工頭模樣（事件分離器：操作系統你幹完了叫我就行）
- 被事件分離器通知的接收器創建http事件處理器解析請求數據
- 某用戶通過瀏覽器想要下載小視頻，於是就上網下
- 模範勞工操作系統把請求數據放在緩衝區中 操作系統：報告老大，搬完了
- 事件分離器把事件完成告訴事件處理器 小工頭事件分離器：操作系統你乾的不錯，但是你的功勞是我的了
- http事件處理器解析緩衝區中保存的請求數據，發現居然有人要下小視頻
- http事件處理器只能悲催的去文件系統中同步的讀文件
- 但是讀完的數據要放在socket連接上，往這上寫又耗時又費力，能不能找個老實人幫我乾呢？ http事件處理器：那個誰，操作系統你過來一下，你把這些磚搬上車
- 操作系統寫操作完成，通知事件分離器。 操作系統：好的老大！ 操作系統：報告！磚搬完了！
- 事件分離器把寫操作完成事件報告給http事件處理器。 事件分離器：報告總指揮，貨已經全部上車。 http事件處理器：不錯，任務完成，又是忙碌的一天 （操作系統：我有句。。。。不知當講不當講）
總結：和一般的非同步操作不同。前攝器模式會把數據的讀寫這種比較耗時的動作交給操作系統去做（底層快啊），而自身只關心操作系統返回的讀寫完成通知，自身做一些解析就好了，這樣就把事件處理和文件操作分離開了（這就是事件處理器的工作）。
到這裡， 前攝器模式就講的差不多啦，其實我一開始也不是很懂這個模式，於是把這個儘量整理成比較好懂的方式，可能有不恰當或者理解錯誤的地方，希望大家能幫我指出來，我進行改正
參考資料：http://www.kuqin.com/ace-2002-12/Part-One/Chapter-8.htm
