飞驴的|站 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
hxhQ贺星河Q的专栏 http://blog.csdn.net/hxhbluestar/category/25379.aspx ACE|络~程
ACE自适配通信环境讨论 http://www.huihoo.org/chat/ace_20030702.html
[ACE技术论文集]一.ACE自适配通信环境Q用于开发通信软g的面向对象网l编E工具包
ACEE序入口函数替换机制分析
[ACE技术论文集]?包装外观QWrapper FacadeQ：用于在类中封装函数的l构型模?/a>
[ACE技术论文集]?IPC SAPQ用于高效、可UL和灵zȝ|络~程的C++包装
[ACE技术论文集]?ACE轻量UOSq发机制的OO装
[ACE技术论文集]?C/C++U程专有存储Q用于访问“per-Thread”状态的对象行ؓ模式
ACE的类l构图[pdf文档]
ACE自适配通信环境
Douglas C. Schmidt
一、ACElD
ACE自适配通信环境QADAPTIVE Communication EnvironmentQ是可以自由使用、开放源码的面向对象QOOQ框ӞFrameworkQ，在其中实C许多用于q发通信软g的核心模式。ACE提供了一l丰富的可复用C++ Wrapper FacadeQ包装外观）和框架组Ӟ可跨多U^台完成通用的通信软gdQ其中包括：事g多\分离和事件处理器分派、信号处理、服务初始化、进E间通信、共享内存管理、消息\由、分布式服务动态（重）配置、ƈ发执行和同步Q等{?br>ACE的目标用h高性能和实旉信服务和应用的开发者。它化了使用q程间通信、事件多路分R显式动态链接和q发的OO|络应用和服务的开发。此外，通过服务在运行时与应用的动态链接，ACEqɾpȝ的配|和重配|得以自动化?br>ACE正在q行持箋的改q。Riverace公司Q?a >http://www.riverace.comQ采用开放源码商业模式对ACEq行商业支持。此外，ACE开发组的许多成员目前正在进行The ACE ORBQTAOQ?a >http://www.cs.wustl.edu/~schmidt/TAO.htmlQ的开发工作?br>二、用ACE的好?br>使用ACE的好处有Q?br>l 增强可移植性：在ACElg的帮助下Q很Ҏ在一UOSq_上编写ƈ发网l应用，然后快速地它们移植到各种其他的OSq_上。而且Q因为ACE是开放源码的自由软gQ你无需担心被锁定在特定的操作系l^台或~译器上?br>l 更好的Y件质量：ACE的设计用了许多可提高Y件质量的关键模式Q这些质量因素包括通信软g灉|性、可扩展性、可复用性和模块性?br>l 更高的效率和可预性：ACEl仔l设计，支持q泛的应用服务质量（QoSQ需求，包括延迟敏感应用的低响应{待旉、高带宽应用的高性能Q以及实时应用的可预性?br>l 更容易{换到标准的高U中间gQTAO使用了ACE提供的可复用lg和模式。它是CORBA的开发源码、遵循标准的实现Qƈ为高性能和实时系l作了优化。ؓ此，ACE和TAO被设计ؓ能良好地协同工作Q以提供全面的中间g解决Ҏ?br>三、ACE的结构和功能
下图昄了ACE中的关键lg以及它们的层ơ关p：
图中的结构和各层的组成部分描q如下?br>四、ACE OS适配?br>该层直接位于用C写成的本地OS API之上。它提供d的类POSIX OS适配层，ACE中的其他层及lg和以下与OS API相关联的q_专有Ҏ屏蔽开来：
l q发和同步：ACE的适配层封装了用于多线E、多q程和同步的OS API?br>l q程间通信QIPCQ和׃n内存QACE的适配层封装了用于本地和远地IPC、以及共享内存的OS API?br>l 事g多\分离机制QACE的适配层封装了用于对基于I/O、定时器、信号和同步的事件进行同步和异步多\分离的OS API?br>l 昑ּ动态链接：ACE的适配层封装了用于昑ּ动态链接的OS API。显式动态链接允许在安装时或q行时对应用服务q行配置?br>l 文gpȝ机制QACE的适配层封装了用于操作文g和目录的OS文gpȝAPI?br>ACE OS适配层的可移植性得ACE可运行在许多操作pȝ上。ACE已在q泛的OSq_上进行了UL和测试，包括Win32Q也是Q在Intel和Alphaq_Q用MSVC++、Borland C++ Builder和IBM Visual Age的WinNT 3.5.x?.x?000、Win95/98和WinCEQ、Mac OS X、大多数版本的UNIXQ例如，SPARC和Intel上的Solaris 1.x?.x、SGI IRIX 5.x?.x、DG/UX、HP-UX 9.x?0.x?1.x、DEC/Compaq UNIX 3.x?.x、AIX 3.x?.x、UnixWare、SCOQ以及可自由使用的UNIX实现Q比如Debian Linux 2.x、RedHat Linux 5.2?.x?.x、FreeBSD和NetBSDQ、实时操作系l（比如QLynxOS、VxWorks、Chorus ClassiX 4.0、QnX Neutrino、RTEMS和PSoSQ、MVS OpenEdition和CRAY UNICOS?br>׃ACE的OS适配层所提供的抽象，所有这些^C用同一代码树。这L设计极大地增ZACE的可UL性和可维护性。此外，q有Java版本的ACE可用Q?a >http://www.cs.wustl.edu/~eea1/JACE.htmlQ?br>五、OS接口的C++ Wrapper Facade
可以直接在ACE OS适配层之上编写高度可UL的C++应用。但是，大多数ACE开发者用的是上图中所C的C++ Wrapper Facade层。通过提供cd安全的C++接口Q这些接口封装ƈ增强本地的OSq发、通信、内存管理、事件多路分R动态链接和文gpȝAPIQ，ACE Wrapper Facade化了应用的开发。应用可以通过有选择地ѝ聚合和/或实例化下面的组件来l合和用这些包装：
l q发和同步组ӞACE对像互斥体和信号量这L本地OS多线E和多进E机制进行抽象，以创建高U的OOq发抽象Q像d对象QActive ObjectQ和多态期货（Polymorphic FutureQ?br>l IPC和文件系l组ӞACE C++包装Ҏ地和/或远地IPC机制q行装Q比如socket、TLI、UNIX FIFO和STREAM道Q以及Win32命名道。此外，ACE C++包装q封装了OS文gpȝAPI?br>l 内存理lgQACE内存理lg为管理进E间׃n内存和进E内堆内存的动态分配和释放提供了灵zd可扩展的抽象?br>ACE C++包装提供了许多与ACE OS适配层一LҎ。但是，q些Ҏ是采用C++cd对象、而不是独立的C函数来构造的。这LOO包装有助于减正地学习和用ACE所需的努力?br>例如QC++的用提高了应用的健壮性，因ؓC++包装是强cd的。所以，~译器可在编译时、而不是运行时类型系l违例。相反，不到q行Ӟ不可能检像socket或文件系lI/Oq样的C一UOS API的类型系l违例?br>ACE采用了许多技术来降低或消除额外的性能开销。例如，ACE大量C用C++内联来消除额外的Ҏ调用开销Q这L开销可由OS适配层和C++包装所提供的额外的cd安全和抽象层ơ带来。此外，对于性能要求很高的包装，比如socket和文件I/O的send/recvҎQACE会避免用虚函数?br>六、框?br>ACEq含有一个高U的|络~程框架Q集成ƈ增强了较低层ơ的C++ Wrapper Facade。该框架支持ƈ发分布式服务动态配|进应用。ACE的框枉分包含以下组Ӟ
l 事g多\分离lgQACE Reactor(反应?和ProactorQ前摄器Q是可扩展的面向对象多\分离器，它们分派应用Ҏ的处理器Q以响应多种cd的基于I/O、定时器、信号和同步的事件?br>l 服务初始化组ӞACE AcceptorQ接受器Q和ConnectorQ连接器Q组件分别d和被动的初始化Q务与初始化一旦完成后通信服务所执行的应用特有的d去耦合?br>l 服务配置lgQACE Service ConfiguratorQ服务配|器Q支持应用的配置Q这些应用的服务可在安装时和/或运行时动态装配?br>l 分层的流lgQACE Streamlg化了像用L协议栈这L由分层服务组成的通信软g应用的开发?br>l ORB适配器组Ӟ通过ORB适配器，ACE可以与单U程和多U程CORBA实现q行无缝集成?br>ACE框架lg便利了通信软g的开发，它们无需修改、重~译、重链接Q或频繁地重启运行中的应用，可被更新和扩展。在ACE中，q样的灵zL是通过l合以下要素来获得的Q（1QC++语言Ҏ，比如模板、承和动态绑定，Q?Q设计模式，比如抽象工厂、策略和服务配置器，以及Q?QOS机制Q比如显式动态链接和多线E?br>七、分布式服务和组?
除了OS适配层、C++ Wrapper Facade和框架组ӞACEq提供了包装成自包含lg的标准分布式服务库。尽这些服务组件ƈ不是ACE框架库的严格l成部分Q它们在ACE中扮演了两种角色Q?br>1. 分解出可复用分布式应用的“积木”：q些服务lg提供通用的分布式应用d的可复用实现Q比如名字服务、事件\由、日志、时间同步和|络锁定?br>2. 演示ACElg的常见用例：q些分布式服务还演示了怎样用像Reactor、Service Configurator、Acceptor和Connector、Active ObjectQ以及IPC包装q样的ACElg来有效地开发灵zR高效和可靠的通信软g?br>八、高U分布式计算中间件组?br>即使用像ACEq样的通信框架Q开发健壮、可扩展和高效的通信应用仍富有挑战性。特别是Q开发者必L握许多复杂的OS和通信的概念，比如Q?br>l |络d和服务标识?br>l 表示转换Q比如加密、压~和在异U终端系l间的字节序转换?br>l q程和线E的创徏和同步?br>l 本地和远地进E间通信QIPCQ机制的pȝ调用和库例程?br>通过采用像CORBA、DCOM或Java RMIq样的高U分布式计算中间Ӟ可以降低开发通信应用的复杂性。高U分布式计算中间仉留在客户端和服务器之_可自动完成分布式应用开发的许多ȝ而易错的斚wQ包括：
l 认证、授权和数据安全?br>l 服务定位和绑定?br>l 服务注册和启用?br>l 事g多\分离和分z?br>l 在像TCPq样的面向字节流的通信协议之上实现消息帧?br>l 涉及|络字节序和参数整编QmarshalingQ的表示转换问题?br>为给通信软g的开发者提供这些特性，在ACE中绑定了下面的高U中间g应用Q?br>1. The ACE ORBQTAOQ：TAO是用ACE提供的框架组件和模式构徏的CORBA实时实现Q包含有|络接口、OS、通信协议和CORBA中间件组件等Ҏ。TAOZ标准的OMG CORBA参考模型，q进行了增强的设计，以克服传l的用于高性能和实时应用的ORB的缺炏VTAO像ACE一P也是可自׃用的开放源码Y件?br>2. JAWSQJAWS是高性能、自适配的Web服务器，使用ACE提供的框架组件和模式构徏。JAWS被构造成“框架的框架”。JAWS的M框架含有以下lg和框Ӟ事g多\分派器、ƈ发策略、I/O{略、协议管道、协议处理器和缓存虚拟文件系l。每个框枉被构造成一l协作对象，通过l合和扩展ACE中的lg来实现。JAWS也是可自׃用的开放源码Y件?br>九、主?br>ACE的主ؓQ?a >http://www.cs.wustl.edu/~schmidt/ACE.htmlQ在q里可获得最新版本的ACE以及其他相关资源?br>Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q＝Q?
|络通信 http://blog.donews.com/dgsheng/archive/2006/03/16/771372.aspx ACE网l编E进行了模式化，以便你不必每ơ都重复相同的代码? |络~程需要处理的事情多括中断Qƈ发，多线E等Q程序格式相对固定，但是健壮的网l程序则相对复杂。ؓ了处理这些情形，ACE内徏了几个网l编E的模式? 最基本的模式当然是直接使用sockq行单客户单服务器单U程的一对一模型Q这U模式相对简单，也和ACE关系不大Q但是这L写的E序不能处理q发的情况，可用性很差或者说基本不具有可用性? 最单的处理q发但是却用单U程的框架在ACE中称为Reactor框架Q在q种框架下，Reactor扮演了协调员的角Ԍ应用E序~制者需要首先写好各U各L事g处理E序Q然后在Reactor中进行登讎ͼReactor以阻塞的方式同时监视所有可能发生的事gQƈ且在相应的事件发生的时候调用对应的处理q程。这U框架解决了在单U程的前提下解决了ƈ发，但是存在一定的问题Q如果某个事件执行过E过长，则可能导致Reactor漏过某些事g? 另外一U单U程处理q发的模式称为异步I/O的Proactor模式Q这U模式和前面介绍的Reactor模式其实区别不大Q唯一的区别之处在于，Servercd对从|络上收到的消息q行处理的时候，后者ƈ不直接让处理器处理收到的消息Q而是首先消息{换ؓ一个消息块l构(ACE_Message_BlockQ通过this->reader_.read函数)Q然后再让相应的处理函数处理已经接收好的消息块结构? 比较一下Reactor框架和Proactor框架Q前者的执行程是： 监视事g->调用事g处理q程->l箋监视事g?后者的执行程是： 监视事g->产生消息->处理消息->释放消息->l箋监视事g。这两种不同的框架在引入各自的多U程概念以后Q就衍生Z同的多线E框架? 前面说过Q用多U程q行|络~程也有两种框架Q半同步/半异步框架和领导?跟随者框架。前者对应的是Proactor框架Q后者对应的是Reactor框架。所谓半同步或者半异步框架Q执行的程是：ȝE负?监视事g->产生消息->攑օ消息队列->监视事g,工作U程则负责从获取消息->处理消息->从消息队列获取另外一个消息?q种框架的优势在于，׃构造消息ƈ且将其放入消息队列的旉是可以控制的Q因此，可以很好的处理网l峰值的情况Q即使出现很高的峰|也不会造成消息的遗漏，但是׃消息存在一个入队列Q出队列的过E，因此性能相较另外一U模型，理论上更差? 后者则是一U相Ҏ复杂的模型，在线E池中只有一个线E是领导者线E，其他随者线E，领导者线E监视事Ӟ在事情发生的时候，首先L另外一个线E变为领D，然后自己再处理事Ӟ处理完成以后Q首先尝试再ơ成为领D，如果试p|Q另外一个线E已l成为领D）Q则自己变成跟随者?q种模型ZReactor模型Q没有消息队列的概念Q由于不存在出入队列的过E，性能相对前者理Z更好。但是如果存在很高的|络蜂拥Q则可能׃所有的U程都在处理各自的事ӞD没有领导者可用，出现数据丢失的可能? 在这两种多线E模型中都存在线E池的用。在半同?半异步模型中Q工作者线E可能ؓ一个工作者线E池。消息队列的U程同步的工作已l由ACE框架自动完成Q是不是工作者线E越多越好呢Q?{案是否定的?多线E可以提高客L响应速度。比如同时有AQB两个客户端先后发起两个请求，Ah完成的时间较长，Bh则可以很快完成，如果只有一个工作线E，那么B需要等待Ah完成以后才能收到自己的响应，对于A来说Q它本来׃期待自己的请求很快被完成Q实际的执行情况会是QA在期待的旉内收到响应，B则用了A的时间才收到自己的响应，B的客h意度׃很差?如果使用多线E，A会gq一点点收到自己的响应，而B也可以在合理的时间内收到自己的响应?但是׃多线E有自己的开销Q就整个pȝ来说Q单工作U程执行A和B的L间回比多工作U程执行ABd的L间要短? 对于领导?跟随者模型中Q必然存在一个对{的U程池，U程池的数目取决于系l能够承受的数目Q单对于模型本w来_U程池的U程数目大Q能够承受的|络蜂拥的极限g大?但是如果执行每个h的时间都很短Q则pȝ中存在大量永q也用不到的U程Q浪费了pȝ的资源? 如果使用多处理器的系l，应用E序必然能够从多U程Q工作线E和跟随者线E）l构中收?
ACE
参考网站：
C++库的代表Q超重量U的|络通信开发框架。ACE自适配通信环境QAdaptive Communication EnvironmentQ是可以自由使用、开放源代码的面向对象框Ӟ在其中实C许多用于q发通信软g的核心模式。ACE提供了一l丰富的可复用C++包装外观QWrapper FacadeQ和框架lgQ可跨越多种q_完成通用的通信软gdQ其中包括：事g多\分离和事件处理器分派、信号处理、服务初始化、进E间通信、共享内存管理、消息\由、分布式服务动态（重）配置、ƈ发执行和同步Q等{?br>StreamModule
参考网站：
设计用于化编写分布式E序的库。尝试着使得~写处理异步行ؓ的程序更ҎQ而不是用同步的外壛_起异步的本质?br>SimpleSocket
参考网站：http://home.hetnet.nl/~lcbokkers/simsock.htm
q个cd让编写基于socket的客?服务器程序更加容易?br>A Stream Socket API for C++
参考网站：
又一个对Socket的封装库?
2008-04-02 23:24
1、WIN32下面用proactor可以辑ֈ几乎RAW IOCP的效率，׃装关系Q应该是差那么一炏V?
客户端处理类的常规写法：
//处理客户端连接消?br>class ClientHandler : public ACE_Service_Handler
{
public:
/**构造函?br>*
*
*/
ClientHandler(unsigned int client_recv_buf_size=SERVER_CLIENT_RECEIVE_BUF_SIZE)
:_read_msg_block(client_recv_buf_size),_io_count(0)
{
}
~ClientHandler(){}
/**
*初始化，因ؓ可能要用到ClientHandler内存池，而这个池又不一定要用NEW
*/
void init();
/**清理函数Q因为可能要用到内存?br>*
*/
void fini();
//查是否超时的函数
void check_time_out(time_t cur_time);
public:
/**客户端连接服务器成功后调?br>*
* \param handle 套接字句?br>* \param &message_block W一ơ读到的数据Q未用）
*/
//由Acceptor来调用！Q！
virtual void open (ACE_HANDLE handle,ACE_Message_Block &message_block);
/**处理|络L作结束消?br>*
* \param &result L作结?br>*/
virtual void handle_read_stream (const ACE_Asynch_Read_Stream::Result &result);
/**处理|络写操作结束消?br>*
* \param &result 写操作结?br>*/
virtual void handle_write_stream (const ACE_Asynch_Write_Stream::Result &result);
private:
//**生成一个网l读h
*
* \param void
* \return 0-成功Q?1p|
*/
int initiate_read_stream (void);
/**生成一个写h
*
* \param mb 待发送的数据
* \param nBytes 待发送数据大?br>* \return 0Q成功，Q?p|
*/
int initiate_write_stream (ACE_Message_Block & mb, size_t nBytes );
/**
*
* \return 查是否可以删除，用的是一个引用计数。每一个外出IO的时候＋1Q每一个IO成功后－1
*/
int check_destroy();
//异步?br>ACE_Asynch_Read_Stream _rs;
//异步?br>ACE_Asynch_Write_Stream _ws;
//接收~冲区只要一个就够了Q因为压根就没想q要多读Q我直到现在也不是很清楚Z么要多读Q多ȝ话要考虑很多问题
ACE_Message_Block _read_msg_block;
//套接字句?q个可以不要了，因ؓ基类有个HANDLER在里面的?br>//ACE_HANDLE _handle;
//一个锁Q客L反正有东东要锁的Q注意，要用ACE_Recursive_Thread_Mutex而不是用ACE_Thread_MutexQ这里面是可以重入的Q而且在WIN32下是直接的EnterCriticalSectionQ可以达到很高的效率
ACE_Recursive_Thread_Mutex _lock;
//在外IO数量,其实是引用计数啦，没啥的。ؓ0的时候就把这个东东关掉啦?br>long _io_count;
//查超时用的，q段旉没东东就CLOSE他了?
time_t _last_net_io;
private:
//本来想用另外一U模型的Q只?个或?个外Q后来想惻I反正一般内存都是够的Q就不管了?
//ACE_Message_Block _send_msg_blocks[2];
//ACE_Message_Block &_sending_msg_block;
//ACE_Message_Block &_idle_msg_block;
private:
public:
//TODO:move to prriva and use friend class!!!
//只是Z效率更高Q不用STL的LIST是因为到现在我没有可用的Node_AllocatorQ所以效率上会有问题?br>ClientHandler *_next;
ClientHandler *next(){return _next;}
void next(ClientHandler *obj){_next=obj;}
};
//q是具体实现Q有些地Ҏ较ؕQ懒得管了，锁的有些地方不对。懒得改了，反正在出错或者有瓉的时候再做也不迟?
void ClientHandler::handle_read_stream (const ACE_Asynch_Read_Stream::Result &result)
{
_last_net_io=ACE_OS::time(NULL);
int byterecved=result.bytes_transferred ();
if ( (result.success ()) && (byterecved != 0))
{
//ACE_DEBUG ((LM_DEBUG, "Receiver completed:%d\n",byterecved));
//处理完数?br> if(handle_received_data()==true)
{
//ACE_DEBUG ((LM_DEBUG, "go on reading...\n"));
//把东东推到头部，处理_包
_read_msg_block.crunch();
initiate_read_stream();
}
}
//q个地方不想用ACE_Atom_opQ因为反正要有一个锁Q而且一般都会用锁，不管了。假如不在意的话Q应该直接用ACE_Atom_Op以达到最好的效率
{
ACE_Guard<ACE_Recursive_Thread_Mutex> locker (_lock);
_io_count--;
}
check_destroy ();
}
void ClientHandler::init()
{
//初始化数据，q不在构造函数里做?br>_last_net_io=ACE_OS::time(NULL);
_read_msg_block.rd_ptr(_read_msg_block.base());
_read_msg_block.wr_ptr(_read_msg_block.base());
this->handle(ACE_INVALID_HANDLE);
}
bool ClientHandler::handle_received_data()
{
...........自己处理
return true;
}
//==================================================================
void ClientHandler::handle_write_stream (const ACE_Asynch_Write_Stream::Result &result)
{
//发送成功，RELEASE?br>//q个不可能有多个RELEASEQ直接XX?br>//result.message_block ().release ();
MsgBlockManager::get_instance().release_msg_block(&result.message_block());
{
ACE_Guard<ACE_Recursive_Thread_Mutex> locker (_lock);
_io_count--;
}
check_destroy ();
}
//bool ClientHandler::destroy ()
//{
// FUNC_ENTER;
// ClientManager::get_instance().release_client_handle(this);
// FUNC_LEAVE;
// return false ;
//}
int ClientHandler::initiate_read_stream (void)
{
ACE_Guard<ACE_Recursive_Thread_Mutex> locker (_lock);
//考虑到粘包的呀
if (_rs.read (_read_msg_block, _read_msg_block.space()) == -1)
{
ACE_ERROR_RETURN ((LM_ERROR,"%p\n","ACE_Asynch_Read_Stream::read"),-1);
}
_io_count++;
return 0;
}
/**生成一个写h
*
* \param mb 待发送的数据
* \param nBytes 待发送数据大?br>* \return 0Q成功，Q?p|
*/
int ClientHandler::initiate_write_stream (ACE_Message_Block & mb, size_t nBytes )
{
ACE_Guard<ACE_Recursive_Thread_Mutex> locker (_lock);
if (_ws.write (mb , nBytes ) == -1)
{
mb.release ();
ACE_ERROR_RETURN((LM_ERROR,"%p\n","ACE_Asynch_Write_File::write"),-1);
}
_io_count++;
return 0;
}
void ClientHandler::open (ACE_HANDLE handle,ACE_Message_Block &message_block)
{
//FUNC_ENTER;
_last_net_io=ACE_OS::time(NULL);
_io_count=0;
if(_ws.open(*this,this->handle())==-1)
{
ACE_ERROR ((LM_ERROR,"%p\n","ACE_Asynch_Write_Stream::open"));
}
else if (_rs.open (*this, this->handle()) == -1)
{
ACE_ERROR ((LM_ERROR,"%p\n","ACE_Asynch_Read_Stream::open"));
}
else
{
initiate_read_stream ();
}
check_destroy();
//FUNC_LEAVE;
}
void ClientHandler::fini()
{
}
void ClientHandler::check_time_out(time_t cur_time)
{
//ACE_Guard<ACE_Recursive_Thread_Mutex> locker (_lock);
//ACE_DEBUG((LM_DEBUG,"cur_time is %u,last io is %u\n",cur_time,_last_net_io));
//是否已lؓ0?br>if(this->handle()==ACE_INVALID_HANDLE)
return;
if(cur_time-_last_net_io>CLIENT_TIME_OUT_SECONDS)
{
ACE_OS::shutdown(this->handle(),SD_BOTH);
ACE_OS::closesocket(this->handle());
this->handle(ACE_INVALID_HANDLE);
}
}
int ClientHandler::check_destroy()
{
{
ACE_Guard<ACE_Recursive_Thread_Mutex> locker (_lock);
if (_io_count> 0)
return 1;
}
ACE_OS::shutdown(this->handle(),SD_BOTH);
ACE_OS::closesocket(this->handle());
this->handle(ACE_INVALID_HANDLE);
//q个地方l内存池吧?br>ClientManager::get_instance().release_client_handle(this);
//delete this;
return 0;
}
]]>
INFOQ?MAPI 是不适用?HTML 邮g
扩展邮g应用~程接口 (MAPI) 应该不是用于生成 HTML 格式的邮件?作ؓ备用Ҏ, 考虑使用 Microsoft Outlook 对象模型?CDONTS?CDOSYSQ?CDOEX 或第三方 SMTP 控g?
回到端更多信息
MAPI 1.0 写入 HTML 邮g开发ƈ不可靠支持创?HTML 格式邮g之前?MAPI 1.0 是由所有版本的 MicrosoftExchange 版本 5.5 通过支持版本 (和所?ServicePackQ?q包括以下从属技术：
?br>?MAPI
?br>扩展 MAPI
?br>OLE 消息
?br>zd消息 Q协作数据对?(CDO) 1.1Q?
?br>CDO 1.21 1.2 和版?
?br>MAPI 控g (Msmapi32.ocx)
如果邮g?HTML 格式, 需要如用于发送其他语a, 中文字其他技术提供更可靠支持?HTML 邮gQ?
?/font> JMail ?br>CDONTS ?br>CDO for Windows 2000 (CDOSYS) ?br>CDO for Exchange 2000 (CDOEX) ?br>Outlook 对象模型?Microsoft Outlook 98 或更高版?/font> ?br>从第三方供应商获取支?SMTP - ActiveX 控g Outlook 如何生成Z MAPI ?HTML 邮g
除ؓ通过 HTMLBody 属性公开什么接口， Outlook 用来生成和?HTML 格式邮g是不公开外部?Outlook ?HTML 数据存储作ؓҎ~码 RTF ?PR_RTF_COMPRESSED MAPI 属性中?有Q何公共接口用于生成?d, 或操作此复杂作?HTML 数据?PR _ BODY 包含邮g正文的纯文本转换? PR_BODY_HTML ?Q?/h6>如果 PR_STORE_SUPPORT_MASK 属性中存储q回 STORE_HTML_OK Ҏ文档 PR_BODY_HTML, 上此属性仅支持由邮件存储?没有 Microsoft 邮g存储支持此标志?某些W三方存储提供程序可能选择支持此标记和属性?
]]>