使用ACE进行网络编程

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任务的总时间要短。

对于领导者/跟随者模型中，必然存在一个对等的线程池，线程池的数目取决于系统能够承受的数目，单就对于模型本身来说，线程池的线程数目越大，能够承受的网络蜂拥的极限值也越大。 但是如果执行每个请求的时间都很短，则系统中存在大量永远也用不到的线程，浪费了系统的资源。

如果使用多处理器的系统，应用程序必然能够从多线程（工作线程和跟随者线程）结构中收益