编写大容量和健壮的服务器系列—处理IOCP资源释放 [转]

编写大容量和健壮的服务器系列—处理IOCP资源释放  2007-08-21 15:24

分类: 默认分类
字号: 大   中   小

 

邓立波 深圳,2007-8

作者联系方式 :

email:         [email protected]

msn:           [email protected]

tel:              13510275799

版权/著作权所有 (C) 2007 邓立波 保留所有权利

警告:未经作者许可,任何人或组织不得转载,公开发布,拷贝,传播本文献的全部或部分

   

1 问题定义

一般的,我们需要在连接关闭(包括主动或被动关闭)时释放以下资源:

(1) 一个或多个接收/发送缓存,一个信令缓存(用作拼包,可能一次WSARecv仅收

到半个信令,这时需要一个缓存先保存这半个信令,继续发出WSARecv 调用,直

到接收到一个完整信令)。

(2) 调用closesocket释放socket资源。

主要的问题是资源何时释放,以及该在哪儿释放。

 

2 缓存如何同socket绑定

方式一

发送缓存绑定到发送操作的OVERLAPPED中(一般通过扩展OVERLAPPED结构添加一个缓存指针变量),接受缓存和信令缓存绑定到接受操作的OVERLAPPED中,如果还有一些资源需要 IOCP处理发送/接收之外的地方访问 ,你可以再动态分配一个的结构体,将其指针同CompletionKey邦定

方式二

使用一个Hash表,对每个连接定义一个连接上下文,按socket值索引,把一些资源,例如信令缓存指针置于hash中的上下文。

 

方式一优点是速度快(其实也快不了多少),但却存在资源在哪儿释放,何时释放的问题。

对此,网络上有两篇文章讨论过:

1  IOCP 中的 socket 错误和资源释放处理方法

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可以不经作者同意任意转载、复制、传播,但任何对本文的引用均须保留本文的作者、出处及本行声明信息!谢谢!

2   狗尾续貂:利用引用计数在多线程中安全释放资源

很惭愧,我无法理解前一篇文章中作者所假设的应用环境,因此我无法判定是否这样真能解决问题,但至少我不放心真的这样做,即使作者是对的,这种“独特”的机制也会让我对服务器的健壮性感到不安。后一文章使用引用计数的方式理论上是可行的,这个引用计数用于跟踪你所分配的结构体的动态释放,因此在所有引用到这个结构体的地方都得做引用计数处理(increment reference或者decrement reference),更要命的是上层应用也可能需要对这个结构体保存一个引用(一般是保存结构体的一个指针,即CompletionKey),因为服务器有时需要主动发送数据到client端。这显然比较麻烦,原本模块内部的复杂性被扩散到上层代码。一点疏急就可能就导致资源泄漏或重复释放,或者访问已经释放的资源而发生内存访问异常,一旦这种bug出现将很难跟踪调试。作为一个基础模块的编写者, 设计时就要考虑这一点,无论谁写的代码,好的结构都可以起到强有力的约束作用,如果不是必要,我建议你不要用这种方式 。最后有一点需要注意的是,如果你没有资源需要在IOCP处理发送/接收之外的地方访问,你就不要去分配一个结构体,以免增加额外的麻烦。

 

第二种方式自然更不会遇到重复资源释放的问题(你可以在任何地方关闭连接,并释放相关资源),因为你释放资源时,同时删除hash表中的连接上下文,所以在释放之前应该检查连接上下文是否存在,如果不存在,则表示资源已被释放。需要注意的是对本次操作的发送/接收缓存应该立刻释放,同时这些缓存指针不必保存到上下文,而是绑定到相应的OVERLAPPED。这种方式还有一个优点,可以跟踪所有连接(例如逐一扫描所有连接,处理一些如心跳包之类的事情)。当然你可能担心hash表毕竟对速度有影响,我们举个例子,你的IOCP一秒种需要处理10万个IO,则需要10万次hash操作,我想说的是 10万次/一秒的hash其实对现在的CPU是非常轻松的,不用担心它成为瓶颈。这种方式相对实现非常简单,出现bug也相对易于跟踪,对于服务器的设计而言,我一直固执的坚持,稳定性始终是第一的

你可能感兴趣的:(编写大容量和健壮的服务器系列—处理IOCP资源释放 [转])