ACE將網(wǎng)絡(luò)編程進行了模式化，以便你不必每次都重復(fù)相同的代碼。
網(wǎng)絡(luò)編程需要處理的事情多括中斷，并發(fā)，多線程等，程序格式相對固定，但是健壯的網(wǎng)絡(luò)程序則相對復(fù)雜。為了處理這些情形，ACE內(nèi)建了幾個網(wǎng)絡(luò)編程的模式。
最基本的模式當然是直接使用sock進行單客戶單服務(wù)器單線程的一對一模型，這種模式相對簡單，也和ACE關(guān)系不大，但是這樣編寫的程序不能處理并發(fā)的情況，可用性很差或者說基本不具有可用性。
最簡單的處理并發(fā)但是卻使用單線程的框架在ACE中稱為Reactor框架，在這種框架下，Reactor扮演了協(xié)調(diào)員的角色，應(yīng)用程序編制者需要首先寫好各種各樣的事件處理程序，然后在Reactor中進行登記，Reactor以阻塞的方式同時監(jiān)視所有可能發(fā)生的事件，并且在相應(yīng)的事件發(fā)生的時候調(diào)用對應(yīng)的處理過程。這種框架解決了在單線程的前提下解決了并發(fā)，但是存在一定的問題，如果某個事件執(zhí)行過程過長，則可能導(dǎo)致Reactor漏過某些事件。
另外一種單線程處理并發(fā)的模式稱為異步I/O的Proactor模式，這種模式和前面介紹的Reactor模式其實區(qū)別不大，的區(qū)別之處在于，Server類在對從網(wǎng)絡(luò)上收到的消息進行處理的時候，后者并不直接讓處理器處理收到的消息，而是首先將消息轉(zhuǎn)換為一個消息塊結(jié)構(gòu)(ACE_Message_Block，通過this->reader_.read函數(shù))，然后再讓相應(yīng)的處理函數(shù)處理已經(jīng)接收好的消息塊結(jié)構(gòu)。
比較一下Reactor框架和Proactor框架，前者的執(zhí)行流程是： 監(jiān)視事件->調(diào)用事件處理過程->繼續(xù)監(jiān)視事件。 后者的執(zhí)行流程是： 監(jiān)視事件->產(chǎn)生消息->處理消息->釋放消息->繼續(xù)監(jiān)視事件。考試,大提示這兩種不同的框架在引入各自的多線程概念以后，就衍生出不同的多線程框架。
前面說過，使用多線程進行網(wǎng)絡(luò)編程也有兩種框架，半同步/半異步框架和/跟隨者框架。前者對應(yīng)的是Proactor框架，后者對應(yīng)的是Reactor框架。所謂半同步或者半異步框架，執(zhí)行的流程是：主線程負責 監(jiān)視事件->產(chǎn)生消息->放入消息隊列->監(jiān)視事件,工作線程則負責從獲取消息->處理消息->從消息隊列獲取另外一個消息。 這種框架的優(yōu)勢在于，由于構(gòu)造消息并且將其放入消息隊列的時間是可以控制的，因此，可以很好的處理網(wǎng)絡(luò)峰值的情況，即使出現(xiàn)很高的峰值，也不會造成消息的遺漏，但是由于消息存在一個入隊列，出隊列的過程，因此性能相較另外一種模型，理論上更差。
后者則是一種相對更復(fù)雜的模型，在線程池中只有一個線程是線程，其他為跟隨者線程，線程監(jiān)視事件，在事情發(fā)生的時候，首先尋找另外一個線程變?yōu)椋缓笞约涸偬幚硎录?，處理完成以后，首先嘗試再次成為，如果嘗試失?。硗庖粋€線程已經(jīng)成為），則自己變成跟隨者。 這種模型基于Reactor模型，沒有消息隊列的概念，由于不存在出入隊列的過程，性能相對前者理論上更好。但是如果存在很高的網(wǎng)絡(luò)蜂擁，則可能由于所有的線程都在處理各自的事件，導(dǎo)致沒有可用，出現(xiàn)數(shù)據(jù)丟失的可能。
在這兩種多線程模型中都存在線程池的使用。在半同步/半異步模型中，工作者線程可能為一個工作者線程池。消息隊列的線程同步的工作已經(jīng)由ACE框架自動完成。
對于/跟隨者模型中，必然存在一個對等的線程池，線程池的數(shù)目取決于系統(tǒng)能夠承受的數(shù)目，單就對于模型本身來說，線程池的線程數(shù)目越大，能夠承受的網(wǎng)絡(luò)蜂擁的極限值也越大。 但是如果執(zhí)行每個請求的時間都很短，則系統(tǒng)中存在大量永遠也用不到的線程，浪費了系統(tǒng)的資源。
如果使用多處理器的系統(tǒng)，應(yīng)用程序必然能夠從多線程（工作線程和跟隨者線程）結(jié)構(gòu)中收益
網(wǎng)絡(luò)編程需要處理的事情多括中斷，并發(fā)，多線程等，程序格式相對固定，但是健壯的網(wǎng)絡(luò)程序則相對復(fù)雜。為了處理這些情形，ACE內(nèi)建了幾個網(wǎng)絡(luò)編程的模式。
最基本的模式當然是直接使用sock進行單客戶單服務(wù)器單線程的一對一模型，這種模式相對簡單，也和ACE關(guān)系不大，但是這樣編寫的程序不能處理并發(fā)的情況，可用性很差或者說基本不具有可用性。
最簡單的處理并發(fā)但是卻使用單線程的框架在ACE中稱為Reactor框架，在這種框架下，Reactor扮演了協(xié)調(diào)員的角色，應(yīng)用程序編制者需要首先寫好各種各樣的事件處理程序，然后在Reactor中進行登記，Reactor以阻塞的方式同時監(jiān)視所有可能發(fā)生的事件，并且在相應(yīng)的事件發(fā)生的時候調(diào)用對應(yīng)的處理過程。這種框架解決了在單線程的前提下解決了并發(fā)，但是存在一定的問題，如果某個事件執(zhí)行過程過長，則可能導(dǎo)致Reactor漏過某些事件。
另外一種單線程處理并發(fā)的模式稱為異步I/O的Proactor模式，這種模式和前面介紹的Reactor模式其實區(qū)別不大，的區(qū)別之處在于，Server類在對從網(wǎng)絡(luò)上收到的消息進行處理的時候，后者并不直接讓處理器處理收到的消息，而是首先將消息轉(zhuǎn)換為一個消息塊結(jié)構(gòu)(ACE_Message_Block，通過this->reader_.read函數(shù))，然后再讓相應(yīng)的處理函數(shù)處理已經(jīng)接收好的消息塊結(jié)構(gòu)。
比較一下Reactor框架和Proactor框架，前者的執(zhí)行流程是： 監(jiān)視事件->調(diào)用事件處理過程->繼續(xù)監(jiān)視事件。 后者的執(zhí)行流程是： 監(jiān)視事件->產(chǎn)生消息->處理消息->釋放消息->繼續(xù)監(jiān)視事件。考試,大提示這兩種不同的框架在引入各自的多線程概念以后，就衍生出不同的多線程框架。
前面說過，使用多線程進行網(wǎng)絡(luò)編程也有兩種框架，半同步/半異步框架和/跟隨者框架。前者對應(yīng)的是Proactor框架，后者對應(yīng)的是Reactor框架。所謂半同步或者半異步框架，執(zhí)行的流程是：主線程負責 監(jiān)視事件->產(chǎn)生消息->放入消息隊列->監(jiān)視事件,工作線程則負責從獲取消息->處理消息->從消息隊列獲取另外一個消息。 這種框架的優(yōu)勢在于，由于構(gòu)造消息并且將其放入消息隊列的時間是可以控制的，因此，可以很好的處理網(wǎng)絡(luò)峰值的情況，即使出現(xiàn)很高的峰值，也不會造成消息的遺漏，但是由于消息存在一個入隊列，出隊列的過程，因此性能相較另外一種模型，理論上更差。
后者則是一種相對更復(fù)雜的模型，在線程池中只有一個線程是線程，其他為跟隨者線程，線程監(jiān)視事件，在事情發(fā)生的時候，首先尋找另外一個線程變?yōu)椋缓笞约涸偬幚硎录?，處理完成以后，首先嘗試再次成為，如果嘗試失?。硗庖粋€線程已經(jīng)成為），則自己變成跟隨者。 這種模型基于Reactor模型，沒有消息隊列的概念，由于不存在出入隊列的過程，性能相對前者理論上更好。但是如果存在很高的網(wǎng)絡(luò)蜂擁，則可能由于所有的線程都在處理各自的事件，導(dǎo)致沒有可用，出現(xiàn)數(shù)據(jù)丟失的可能。
在這兩種多線程模型中都存在線程池的使用。在半同步/半異步模型中，工作者線程可能為一個工作者線程池。消息隊列的線程同步的工作已經(jīng)由ACE框架自動完成。
對于/跟隨者模型中，必然存在一個對等的線程池，線程池的數(shù)目取決于系統(tǒng)能夠承受的數(shù)目，單就對于模型本身來說，線程池的線程數(shù)目越大，能夠承受的網(wǎng)絡(luò)蜂擁的極限值也越大。 但是如果執(zhí)行每個請求的時間都很短，則系統(tǒng)中存在大量永遠也用不到的線程，浪費了系統(tǒng)的資源。
如果使用多處理器的系統(tǒng)，應(yīng)用程序必然能夠從多線程（工作線程和跟隨者線程）結(jié)構(gòu)中收益