本文同步自游戲人生

o *__ 序 __* o

在閱讀ACE代碼和C++NPv1, v2, APG的時候，我意識到一個問題：雖然稍有C++和網(wǎng)絡基礎的同學都可以讀懂ACE，但如果你對OS（五大管理模塊都包含在內(nèi)）、TCP/IP、C++、Design Patterns了解越多，你就越能體會ACE為什么需要這么龐雜，雖然它不夠完美（但至少我還沒有資格來批評這一點，我現(xiàn)在最常想做的一個動作就是五體投地）。

而且我隱約感覺到，我現(xiàn)在所寫的很多東西在以后（對于有些人或許就是現(xiàn)在）看來會相當不深刻、相當不嚴謹，但對于一段學習歷程，這個過程是必然的、必需的。

在C++NPv1中，Douglas C. Schmidt把原始socket及其API的缺陷有些妖魔化了，比如一段加上注釋、空行在內(nèi)的35行的代碼，被指出有10處錯誤之多。這就像很多其他語言的倡導者或反傳統(tǒng)C/C++指針者在批評指針時的說法一樣。長期使用原始socket和指針的同學對此感覺很不舒服，何況socket API提供了大量錯誤檢測的接口，至多是不夠友好罷了。你好就好了，沒必要抓住別人一頓痛批吧，『本是同根生，相煎何太急』。

雖然Solaris、Linux的很多版本及Windows對起源于Berkeley的socket API進行了重寫，但不可否認，由于歷史原因和POSIX標準的存在，對于使用者而言，我們可以無視這些API的實現(xiàn)差異。只是一旦我們從socket通信擴展到其他IPC通信的話，就需要正視各種I/O細節(jié)的差異了。

由于UNIX中，對于socket, file, pipe, device的大多數(shù)操作，描述符都是通用的（這一點，OS上面講的更清楚些）。而Windows中，句柄大多不能互換（socket對于MS來說是舶來品）。系統(tǒng)和標準的不一致導致地址、協(xié)議和API的混雜甚至混亂。

UNIX下的描述符和Windows的句柄可以看作是同一個概念，只是應用環(huán)境不一樣，所描述的內(nèi)容也時常不一樣，再簡單了說，它們都是一個整型的ID。

ACE的源碼中使用了大量預處理指令，尤其在跨平臺/編譯環(huán)境的部分更加明顯。鑒于C/C++標準的博大胸懷，有些指令需要閱讀相關編譯器提供的幫助文檔：

o #pragma: GCC, MSVC

o #define (#, #@, ##) : GCC, MSVC

其中有若干代碼文件以.inl為后綴，里面是對部分函數(shù)的內(nèi)聯(lián)實現(xiàn)，以使代碼結構看上去更加簡潔。如果確定使用內(nèi)聯(lián)函數(shù)的話，*.inl將被包含于*.h的最后，如果不使用，則像*.h一樣，包含于*.cpp的頭部。

ACE采用doxygen輸出文檔，在閱讀代碼注釋時能夠感受到差異，但基本不會影響閱讀。

o * __ 關于第3章（C++NPv1）__ * o

ACE抽象的地址類ACE_Addr擁有ACE_DEV_Addr, ACE_FILE_Addr, ACE_INET_Addr, ACE_SPIPE_Addr, ACE_UNIX_Addr五個子類。對于狹義上的網(wǎng)絡通信（TCP/IP）而言，ACE_INET_Addr對應于我們熟悉的sockaddr_in。

ACE_IPC_SAP是IPC（interprocess communication）I/O操作類的root類。

從編碼的角度看，這個類漂亮的地方在于示例了抽象類的另一種實現(xiàn)方式。

一提到抽象類，大多數(shù)人的第一反應是pure virtual function。當一個基類確定需要使用virtual function時，這是一個不錯的選擇。但我們都知道虛擬函數(shù)有開銷。而且對于一個結構簡單的抽象基類和其繼承子類（尤其是大量使用時），一個虛函數(shù)表帶來的開銷會讓整個設計顯得十分蹩腳。

我們都知道如何強制讓一個類無法使用default constructor（protected）。如果對基類使用該方法，僅使子類具有public的default constructor，這就達到了定義抽象基類的效果。

virtual destructor的意義在于防止delete父類指針（指向子類對象）時未調(diào)用子類destructor。在此例中，為避免這種情況，同樣將destructor聲明為protected即可。

從設計實現(xiàn)的角度看，相較于socket API，ACE_IPC_SAP的子類ACE_SOCK提供了編譯時對句柄合法性的檢測。

從邏輯功能層面劃分，socket有三種角色：

o active connection role (connector)：主動連接

o passive connection role (acceptor)：被動連接

o communication role (stream)：數(shù)據(jù)通信

但socket API畢竟不是OOD出來的，對于一個socket描述符，也完全沒有必要去限制其擔負的功能，更不可能搞成三種不同的socket。而OOD的ACE則可以輕易實現(xiàn)對socket對象及其操作的封裝。

工廠類ACE_SOCK_Connector是一個主動創(chuàng)建通信端的工廠類。socket API中的connect接口只是為一個socket建立與其它peer的網(wǎng)絡連接，而不產(chǎn)生新的socket實例，也不依賴于任何其它socket。同樣，ACE_SOCK_Connector只是為一個ACE_SOCK_Stream對象（對用于數(shù)據(jù)通信的socket的封裝）連接到ACE_Addr（對struct sockaddr的封裝）提供接口，也不含對ACE_SOCK_Stream對象的其它操作。

工廠類ACE_SOCK_Acceptor是一個被動創(chuàng)建通信端的工廠類。當監(jiān)聽到新的網(wǎng)絡連接后，為該連接初始化一個ACE_SOCK_Stream對象。和connector不同的是，acceptor依賴于一個已經(jīng)存在的充當監(jiān)聽功能的socket句柄（ACE_SOCK），因此，ACE_SOCK_Acceptor是ACE_SOCK的一個子類。

ACE_SOCK_Stream是只負有通信傳輸功能的socket，對應connection-oriented的TCP通信格式stream，和UDP的CE_SOCK_CODgram相呼應。ACE_SOCK_Stream只是socket的通信載體，在兩個工廠ACE_SOCK_Connector和ACE_SOCK_Acceptor中初始化。這樣一個類除支持最基本的數(shù)據(jù)發(fā)送（send）和接收（recv）和阻塞（blocking）、非阻塞（nonblocking）及定時（timed）的I/O模式外，還支持分散讀取（scatter-read）和集中寫入（gather-write）。

對于一個簡單的『網(wǎng)絡課程作業(yè)：寫一個有連接的IM小程序』，上面這些內(nèi)容已經(jīng)足夠了。當然即使使用對應的幾個socket API也已經(jīng)足夠了。但我們顯然更加關心如此龐大的一個庫，是如何解決復雜的網(wǎng)絡應用的，我尤其關心的是多線程并發(fā)如何更好的處理。

所以，我準備跑到第8、9章了。