ACE將網絡編程進行了模式化，以便你不必每次都重復相同的代碼。 網絡編程需要處理的事情多括中斷，并發，多線程等，程序格式相對固定，但是健壯的網絡程序則相對復雜。為了處理這些情形，ACE內建了幾個網絡編程的模式。 最基本的模式當然是直接使用sock進行單客戶單服務器單線程的一對一模型，這種模式相對簡單，也和ACE關系不大，但是這樣編寫的程序不能處理并發的情況，可用性很差或者說基本不具有可用性。 最簡單的處理并發但是卻使用單線程的框架在ACE中稱為Reactor框架，在這種框架下，Reactor扮演了協調員的角色，應用程序編制者需要首先寫好各種各樣的事件處理程序，然后在Reactor中進行登記，Reactor以阻塞的方式同時監視所有可能發生的事件，并且在相應的事件發生的時候調用對應的處理過程。這種框架解決了在單線程的前提下解決了并發，但是存在一定的問題，如果某個事件執行過程過長，則可能導致Reactor漏過某些事件。 另外一種單線程處理并發的模式稱為異步I/O的Proactor模式，這種模式和前面介紹的Reactor模式其實區別不大，唯一的區別之處在于，Server類在對從網絡上收到的消息進行處理的時候，后者并不直接讓處理器處理收到的消息，而是首先將消息轉換為一個消息塊結構(ACE_Message_Block，通過this->reader_.read函數)，然后再讓相應的處理函數處理已經接收好的消息塊結構。 比較一下Reactor框架和Proactor框架，前者的執行流程是： 監視事件->調用事件處理過程->繼續監視事件。 后者的執行流程是： 監視事件->產生消息->處理消息->釋放消息->繼續監視事件。這兩種不同的框架在引入各自的多線程概念以后，就衍生出不同的多線程框架。 前面說過，使用多線程進行網絡編程也有兩種框架，半同步/半異步框架和領導者/跟隨者框架。前者對應的是Proactor框架，后者對應的是Reactor框架。所謂半同步或者半異步框架，執行的流程是：主線程負責 監視事件->產生消息->放入消息隊列->監視事件,工作線程則負責從獲取消息->處理消息->從消息隊列獲取另外一個消息。 這種框架的優勢在于，由于構造消息并且將其放入消息隊列的時間是可以控制的，因此，可以很好的處理網絡峰值的情況，即使出現很高的峰值，也不會造成消息的遺漏，但是由于消息存在一個入隊列，出隊列的過程，因此性能相較另外一種模型，理論上更差。 后者則是一種相對更復雜的模型，在線程池中只有一個線程是領導者線程，其他為跟隨者線程，領導者線程監視事件，在事情發生的時候，首先尋找另外一個線程變為領導者，然后自己再處理事件，處理完成以后，首先嘗試再次成為領導者，如果嘗試失敗（另外一個線程已經成為領導者），則自己變成跟隨者。 這種模型基于Reactor模型，沒有消息隊列的概念，由于不存在出入隊列的過程，性能相對前者理論上更好。但是如果存在很高的網絡蜂擁，則可能由于所有的線程都在處理各自的事件，導致沒有領導者可用，出現數據丟失的可能。 在這兩種多線程模型中都存在線程池的使用。在半同步/半異步模型中，工作者線程可能為一個工作者線程池。消息隊列的線程同步的工作已經由ACE框架自動完成，是不是工作者線程越多越好呢？ 答案是否定的。 多線程可以提高客戶的響應速度。比如同時有A，B兩個客戶端先后發起兩個請求，A請求完成的時間較長，B請求則可以很快完成，如果只有一個工作線程，那么B需要等待A請求完成以后才能收到自己的響應，對于A來說，它本來就不期待自己的請求很快被完成，實際的執行情況會是，A在期待的時間內收到響應，B則使用了A的時間才收到自己的響應，B的客戶滿意度就會很差。 如果使用多線程，A會延遲一點點收到自己的響應，而B也可以在合理的時間內收到自己的響應。 但是由于多線程有自己的開銷，就整個系統來說，單工作線程執行A和B的總時間回比多工作線程執行AB任務的總時間要短。 對于領導者/跟隨者模型中，必然存在一個對等的線程池，線程池的數目取決于系統能夠承受的數目，單就對于模型本身來說，線程池的線程數目越大，能夠承受的網絡蜂擁的極限值也越大。 但是如果執行每個請求的時間都很短，則系統中存在大量永遠也用不到的線程，浪費了系統的資源。 如果使用多處理器的系統，應用程序必然能夠從多線程（工作線程和跟隨者線程）結構中收益。 C++網絡編程 ACE相關資料收集 2008-01-10 13:38

小飛驢的網站 http://www.flyingdonkey.com/ 馬維達 C++網絡編程 卷二 譯者 http://www.flyingdonkey.com/cgi-bin/LB5000MX/leoboard.cgi WeiZone 我們的社區 http://www.weizone.com/forumdisplay.php?fid=22&page=1 ACE網絡通訊編程版 LoveUnix技術論壇 http://www.loveunix.com/viewthread.php?tid=29276 hxh（賀星河）的專欄 http://blog.csdn.net/hxhbluestar/category/25379.aspx ACE網絡編程 ACE自適配通信環境討論 http://www.huihoo.org/chat/ace_20030702.html [ACE技術論文集]一.ACE自適配通信環境：用于開發通信軟件的面向對象網絡編程工具包 ACE程序入口函數替換機制分析 [ACE技術論文集]二 包裝外觀（Wrapper Facade）：用于在類中封裝函數的結構型模式 [ACE技術論文集]三 IPC SAP：用于高效、可移植和靈活的網絡編程的C++包裝 [ACE技術論文集]四 ACE輕量級OS并發機制的OO封裝 [ACE技術論文集]五 C/C++線程專有存儲：用于訪問“per-Thread”狀態的對象行為模式 ACE的類結構圖[pdf文檔] ACE自適配通信環境 Douglas C. Schmidt 一、ACE綜述 　　ACE自適配通信環境（ADAPTIVE Communication Environment）是可以自由使用、開放源碼的面向對象（OO）框架（Framework），在其中實現了許多用于并發通信軟件的核心模式。ACE提供了一組豐富的可復用C++ Wrapper Facade（包裝外觀）和框架組件，可跨越多種平臺完成通用的通信軟件任務，其中包括：事件多路分離和事件處理器分派、信號處理、服務初始化、進程間通信、共享內存管理、消息路由、分布式服務動態（重）配置、并發執行和同步，等等。 ACE的目標用戶是高性能和實時通信服務和應用的開發者。它簡化了使用進程間通信、事件多路分離、顯式動態鏈接和并發的OO網絡應用和服務的開發。此外，通過服務在運行時與應用的動態鏈接，ACE還使系統的配置和重配置得以自動化。 ACE正在進行持續的改進。Riverace公司（http://www.riverace.com）采用開放源碼商業模式對ACE進行商業支持。此外，ACE開發組的許多成員目前正在進行The ACE ORB（TAO，http://www.cs.wustl.edu/~schmidt/TAO.html）的開發工作。 二、使用ACE的好處 使用ACE的好處有： l ?? 增強可移植性：在ACE組件的幫助下，很容易在一種OS平臺上編寫并發網絡應用，然后快速地將它們移植到各種其他的OS平臺上。而且，因為ACE是開放源碼的自由軟件，你無需擔心被鎖定在特定的操作系統平臺或編譯器上。 l ?? 更好的軟件質量：ACE的設計使用了許多可提高軟件質量的關鍵模式，這些質量因素包括通信軟件靈活性、可擴展性、可復用性和模塊性。 l ?? 更高的效率和可預測性：ACE經仔細設計，支持廣泛的應用服務質量（QoS）需求，包括延遲敏感應用的低響應等待時間、高帶寬應用的高性能，以及實時應用的可預測性。 l ?? 更容易轉換到標準的高級中間件：TAO使用了ACE提供的可復用組件和模式。它是CORBA的開發源碼、遵循標準的實現，并為高性能和實時系統作了優化。為此，ACE和TAO被設計為能良好地協同工作，以提供全面的中間件解決方案。 三、ACE的結構和功能 下圖顯示了ACE中的關鍵組件以及它們的層次關系： 圖中的結構和各層的組成部分描述如下。 四、ACE OS適配層 該層直接位于用C寫成的本地OS API之上。它提供輕型的類POSIX OS適配層，將ACE中的其他層及組件和以下與OS API相關聯的平臺專有特性屏蔽開來： l ?? 并發和同步：ACE的適配層封裝了用于多線程、多進程和同步的OS API。 l ?? 進程間通信（IPC）和共享內存：ACE的適配層封裝了用于本地和遠地IPC、以及共享內存的OS API。 l ?? 事件多路分離機制：ACE的適配層封裝了用于對基于I/O、定時器、信號和同步的事件進行同步和異步多路分離的OS API。 l ?? 顯式動態鏈接：ACE的適配層封裝了用于顯式動態鏈接的OS API。顯式動態鏈接允許在安裝時或運行時對應用服務進行配置。 l ?? 文件系統機制：ACE的適配層封裝了用于操作文件和目錄的OS文件系統API。 ACE OS適配層的可移植性使得ACE可運行在許多操作系統上。ACE已在廣泛的OS平臺上進行了移植和測試，包括Win32（也就是，在Intel和Alpha平臺，使用MSVC++、Borland C++ Builder和IBM Visual Age的WinNT 3.5.x、4.x、2000、Win95/98和WinCE）、Mac OS X、大多數版本的UNIX（例如，SPARC和Intel上的Solaris 1.x和2.x、SGI IRIX 5.x和6.x、DG/UX、HP-UX 9.x、10.x和11.x、DEC/Compaq UNIX 3.x和4.x、AIX 3.x和4.x、UnixWare、SCO，以及可自由使用的UNIX實現，比如Debian Linux 2.x、RedHat Linux 5.2、6.x和7.x、FreeBSD和NetBSD）、實時操作系統（比如，LynxOS、VxWorks、Chorus ClassiX 4.0、QnX Neutrino、RTEMS和PSoS）、MVS OpenEdition和CRAY UNICOS。 由于ACE的OS適配層所提供的抽象，所有這些平臺使用同一棵代碼樹。這樣的設計極大地增強了ACE的可移植性和可維護性。此外，還有Java版本的ACE可用（http://www.cs.wustl.edu/~eea1/JACE.html）。 五、OS接口的C++ Wrapper Facade 可以直接在ACE OS適配層之上編寫高度可移植的C++應用。但是，大多數ACE開發者使用的是上圖中所示的C++ Wrapper Facade層。通過提供類型安全的C++接口（這些接口封裝并增強本地的OS并發、通信、內存管理、事件多路分離、動態鏈接和文件系統API），ACE Wrapper Facade簡化了應用的開發。應用可以通過有選擇地繼承、聚合和/或實例化下面的組件來組合和使用這些包裝： l ?? 并發和同步組件：ACE對像互斥體和信號量這樣的本地OS多線程和多進程機制進行抽象，以創建高級的OO并發抽象，像主動對象（Active Object）和多態期貨（Polymorphic Future）。 l ?? IPC和文件系統組件：ACE C++包裝對本地和/或遠地IPC機制進行封裝，比如socket、TLI、UNIX FIFO和STREAM管道，以及Win32命名管道。此外，ACE C++包裝還封裝了OS文件系統API。 l ?? 內存管理組件：ACE內存管理組件為管理進程間共享內存和進程內堆內存的動態分配和釋放提供了靈活和可擴展的抽象。 ACE C++包裝提供了許多與ACE OS適配層一樣的特性。但是，這些特性是采用C++類和對象、而不是獨立的C函數來構造的。這樣的OO包裝有助于減少正確地學習和使用ACE所需的努力。 例如，C++的使用提高了應用的健壯性，因為C++包裝是強類型的。所以，編譯器可在編譯時、而不是運行時檢測類型系統違例。相反，不到運行時，不可能檢測像socket或文件系統I/O這樣的C一級OS API的類型系統違例。 ACE采用了許多技術來降低或消除額外的性能開銷。例如，ACE大量地使用C++內聯來消除額外的方法調用開銷；這樣的開銷可由OS適配層和C++包裝所提供的額外的類型安全和抽象層次帶來。此外，對于性能要求很高的包裝，比如socket和文件I/O的send/recv方法，ACE會避免使用虛函數。 六、框架 ACE還含有一個高級的網絡編程框架，集成并增強了較低層次的C++ Wrapper Facade。該框架支持將并發分布式服務動態配置進應用。ACE的框架部分包含以下組件： l ?? 事件多路分離組件：ACE Reactor(反應器)和Proactor（前攝器）是可擴展的面向對象多路分離器，它們分派應用特有的處理器，以響應多種類型的基于I/O、定時器、信號和同步的事件。 l ?? 服務初始化組件：ACE Acceptor（接受器）和Connector（連接器）組件分別使主動和被動的初始化任務與初始化一旦完成后通信服務所執行的應用特有的任務去耦合。 l ?? 服務配置組件：ACE Service Configurator（服務配置器）支持應用的配置，這些應用的服務可在安裝時和/或運行時動態裝配。 l ?? 分層的流組件：ACE Stream組件簡化了像用戶級協議棧這樣的由分層服務組成的通信軟件應用的開發。 l ?? ORB適配器組件：通過ORB適配器，ACE可以與單線程和多線程CORBA實現進行無縫集成。 ACE框架組件便利了通信軟件的開發，它們無需修改、重編譯、重鏈接，或頻繁地重啟運行中的應用，就可被更新和擴展。在ACE中，這樣的靈活性是通過結合以下要素來獲得的：（1）C++語言特性，比如模板、繼承和動態綁定，（2）設計模式，比如抽象工廠、策略和服務配置器，以及（3）OS機制，比如顯式動態鏈接和多線程。 七、分布式服務和組件 除了OS適配層、C++ Wrapper Facade和框架組件，ACE還提供了包裝成自包含組件的標準分布式服務庫。盡管這些服務組件并不是ACE框架庫的嚴格組成部分，它們在ACE中扮演了兩種角色： 1. ?? 分解出可復用分布式應用的“積木”：這些服務組件提供通用的分布式應用任務的可復用實現，比如名字服務、事件路由、日志、時間同步和網絡鎖定。 2. ?? 演示ACE組件的常見用例：這些分布式服務還演示了怎樣用像Reactor、Service Configurator、Acceptor和Connector、Active Object，以及IPC包裝這樣的ACE組件來有效地開發靈活、高效和可靠的通信軟件。 八、高級分布式計算中間件組件 即使使用像ACE這樣的通信框架，開發健壯、可擴展和高效的通信應用仍富有挑戰性。特別是，開發者必須掌握許多復雜的OS和通信的概念，比如： l ?? 網絡尋址和服務標識。 l ?? 表示轉換，比如加密、壓縮和在異種終端系統間的字節序轉換。 l ?? 進程和線程的創建和同步。 l ?? 本地和遠地進程間通信（IPC）機制的系統調用和庫例程。 通過采用像CORBA、DCOM或Java RMI這樣的高級分布式計算中間件，可以降低開發通信應用的復雜性。高級分布式計算中間件駐留在客戶端和服務器之間，可自動完成分布式應用開發的許多麻煩而易錯的方面，包括： l ?? 認證、授權和數據安全。 l ?? 服務定位和綁定。 l ?? 服務注冊和啟用。 l ?? 事件多路分離和分派。 l ?? 在像TCP這樣的面向字節流的通信協議之上實現消息幀。 l ?? 涉及網絡字節序和參數整編（marshaling）的表示轉換問題。 為給通信軟件的開發者提供這些特性，在ACE中綁定了下面的高級中間件應用： 1. ?? The ACE ORB（TAO）：TAO是使用ACE提供的框架組件和模式構建的CORBA實時實現，包含有網絡接口、OS、通信協議和CORBA中間件組件等特性。TAO基于標準的OMG CORBA參考模型，并進行了增強的設計，以克服傳統的用于高性能和實時應用的ORB的缺點。TAO像ACE一樣，也是可自由使用的開放源碼軟件。 2. ?? JAWS：JAWS是高性能、自適配的Web服務器，使用ACE提供的框架組件和模式構建。JAWS被構造成“框架的框架”。JAWS的總體框架含有以下組件和框架：事件多路分派器、并發策略、I/O策略、協議管道、協議處理器和緩存虛擬文件系統。每個框架都被構造成一組協作對象，通過組合和擴展ACE中的組件來實現。JAWS也是可自由使用的開放源碼軟件。 九、主頁 ACE的主頁為：http://www.cs.wustl.edu/~schmidt/ACE.html，在這里可獲得最新版本的ACE以及其他相關資源。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 網絡通信 ACE 參考網站：http://www.c'>http://www.c'>http://www.c'>http://www.cs.wustl.edu/~schmidt/ACE.html C++庫的代表，超重量級的網絡通信開發框架。ACE自適配通信環境（Adaptive Communication Environment）是可以自由使用、開放源代碼的面向對象框架，在其中實現了許多用于并發通信軟件的核心模式。ACE提供了一組豐富的可復用C++包裝外觀（Wrapper Facade）和框架組件，可跨越多種平臺完成通用的通信軟件任務，其中包括：事件多路分離和事件處理器分派、信號處理、服務初始化、進程間通信、共享內存管理、消息路由、分布式服務動態（重）配置、并發執行和同步，等等。 StreamModule 參考網站：http://www.omnifarious.org/StrMod/'>http://www.omnifarious.org/StrMod/ 設計用于簡化編寫分布式程序的庫。嘗試著使得編寫處理異步行為的程序更容易，而不是用同步的外殼包起異步的本質。 SimpleSocket 參考網站：http://home.hetnet.nl/~lcbokkers/simsock.htm 這個類庫讓編寫基于socket的客戶/服務器程序更加容易。 A Stream Socket API for C++ 參考網站：http://www.pcs.cnu.edu/'>http://www.pcs.cnu.edu/~dgame/sockets/socketsC++/sockets.html 又一個對Socket的封裝庫。 http://blog.donews.com/dgsheng/archive/2006/03/16/771372.aspx

ACE網絡開發中，各種Reactor實現的總結 from http://www.acejoy.com?ACE網絡編程開發網
author:kylin 大家好，第一次來這個屬于ACEer的地方真的很高興啊！下面就ACE中現有的三種Reactor做一些總結，都是我個人使用的經驗，如有不妥還請指教。 最近，偶在ACE_Reactor框架和ACE_Proactor框架的基礎上寫了一個網絡應用框架，主要目的是將網絡數據收發，網絡錯誤處理，以及網絡超時這些socket級的問題與應用邏輯分開，可以保證在應用邏輯的實現不變的情況下，隨意改變網絡層的實現（也就是用同步IO的ACE_Reactor框架或者用ACE_Proactor框架實現socket上的數據收發，超時及錯誤處理）。寫這個網絡應用框架的過程中遇到了很多問題，不得不去看ACE_Reactor框架和ACE_Proactor框架的源代碼，所以最后對這兩個框架有了更深的認識。下面說說ACE_Reactor框架，都是我個人使用的經驗，如有不妥還請指教。 現有的ACE庫中提供了三種主要的Reactor實現（更多新的實現到官方網站上應該可以找到），ACE_Select_Reactor, ACE_TP_Reactor和ACE_WFMO_Reactor。三種實現的使用都有不同的注意事項： （1）ACE_WFMO_Reactor：這個實現是基于Win32的Socket Event-select模型，也就是用一個win32 的手動重置event與一個socket相關聯(調用WSAEventSelect函數并指明關心哪些socket事件，如可讀，可寫等），用WaitForMutiple0bjects來實現多路IO監視，當這個函數返回后調用WSAEnumNetworkEvents檢查socket上發生了那種事件（可讀或可寫）。?? 這個實現問題最大。 首先，它的致命傷在于每一個ACE_WFMO_Reactor只能同時監視64個socket（具體說是62個，有2個用于notify()和參與event-loop線程的喚醒同步）；其次，就是它的可寫條件非常詭異，只有當socket內部寫緩沖區從滿到不滿時才算可寫，因此，向它register_event 寫事件時不出意外的話一定出錯（第一次寫成功，以后就再寫不了了）。因此，這個實現用途很有限。不過，這個實現可以保證多個線程同時對同一個reactor執行event_loop，為了達到這個目的，它在多線程同步上下了很多工夫，讀它的源代碼會是很好的學習機會（牛人寫的就是不一樣啊，win32 event的使用簡直是登峰造極）。 （2）ACE_Select_Reactor：這個實現中歸中舉，不要忘記在線程執行event_loop前成為這個reactor的owner。值得學習的是實現中使用的那把鎖的實現, 即ACE_Token類，以后自己寫程序的時候可以用得上，比mutex強很多。另外就是notify()的實現，也就是那個ACE_Pipe類，說白了就是本地回環socket來實現線程間通信。這個實現和（1）可以在其他線程（也就是沒有執行Reactor_Event_Loop的線程）中安全的調用Remove_Handler，這個很方便，一般就可以在handle_close()方法里面做清理handler的工作。但是有一個問題注意，要自己跟蹤每個handler注冊了那些事件，只有向reactor注銷了這些時間后才能delete這個handler。這個問題在C++ NPv2中強調過。這個實現默認是可以同時監視1024個socket，不過可惜的是只能一個線程執行Reactor_Event_Loop。 （3）ACE_TP_Reactor：這個是我最喜歡的了，但是如果不清楚它的實現的話會很容易出錯。如果你使用了多個線程run_reactor_event_loop：首先，在默認情況下，你不能象前兩個實現那樣在不需要某個handler的情況下安全的調用remove_handler()；其次，你需要在handle_input()，和handle_timeout()以及handle_output()，和handle_timeout()中考慮同步，注意是handle_**put與handle_timeout（）之間才有同步問題，而handle_input()和handle_output()之間不用考慮。解決第一個問題的辦法是在ACE_Event_handler中啟動reference_count，并且改變刪除策略：在handle_close()中不進行任何清除工作，而是將ACE_Event_handler的reference_count減一，而清除工作應該在析構函數中進行。那么，delete是誰調用呢---是reactor框架ACE_Event_handler在reference_count為0時幫你調用。總之，這個實現的使用要比其他的復雜。 總之，Reactor的使用遠比那幾本書上講的要復雜得多，如果不徹底了解它是怎么實現的，在使用過程中難免會碰到許多問題。所以，我的建議是，看源代碼！這樣不僅可以深入理解Reactor框架，少犯錯誤，還可以學習大牛們怎么寫程序的，特別是對于設計模式，還有操作系統API的靈活使用。關于ACE_Proactor的下次再聊。

提一些自己的看法，大家討論。

1、ACE_WFMO_Reactor部分，向它register_event 寫事件時不出意外的話一定出錯，應用中沒發現，因為這個實現中， 事件在當前狀態變化時候觸發，而不是基于當前狀態觸發。所以，注冊了寫標志后，你就一直發送就行了，直到它告訴你不成了，再等待handle_output()被觸發。
2、ACE_Select_Reactor部分，不過可惜的是只能一個線程執行Reactor_Event_Loop，這個不準確。準確的說，是在某一時刻只能被一個線程執行?？梢允褂枚鄠€線程，但是每個線程循環中必須使用owner()方法設置所有者線程。

總結

以上是生活随笔為你收集整理的ACE网络编程模式比较的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。