小飛驢的網站 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將網絡編程進行了模式化，以便你不必每次都重複相同的代碼。
網絡編程需要處理的事情多括中斷，併發，多線程等，程序格式相對固定，但是健壯的網絡程序則相對複雜。爲了處理這些情形，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任務的總時間要短。
對於領導者/跟隨者模型中，必然存在一個對等的線程池，線程池的數目取決於系統能夠承受的數目，單就對於模型本身來說，線程池的線程數目越大，能夠承受的網絡蜂擁的極限值也越大。 但是如果執行每個請求的時間都很短，則系統中存在大量永遠也用不到的線程，浪費了系統的資源。
如果使用多處理器的系統，應用程序必然能夠從多線程（工作線程和跟隨者線程）結構中收益