烽驿2009开源实时通信平台开工了！

 烽驿2009开源实时通信平台的第一行代码终于上传了， 开发语言C++，目前支持平台Linux，Windows。

源码位置：svn checkout http://fy2009.googlecode.com/svn/trunk/ fy2009

欢迎同道中人能给予持续关注，并提供宝贵意见，帮助测试及Review Code。该项目采用较宽松的“New BSD”许可证类型。

目前刚刚起了个头，看着她长大吧！

 

今天只上传了一个项目结构，如简单的README， LICENSE以及Linux下的Makefile，Windows下的工程文件，以及一个基本的头文件，定义了该项目采用的namespace, 一些基本类型的Typedef，最基本的Trace及Try...Catch结构。另外，实现了一个较重要的定制的Buffer类型模板buffer_tt(顺便介绍一下本项目的一个命名约定：所有Class等类型定义，都以_t(type)为后缀，类型模板则以_tt(type template)为后缀,接口定义将以_it(interface)为后缀。

实现这个buffer_tt模板基于这样的考虑：对内存Buffer的操作在通信类软件中非常频繁，基于Stack的Buffer，优点是高效，缺点是大小不容易控制，且Linux下，用pthread_create创建的线程，缺省情格下Stack尺寸较小，对于大容量的通信服务器应用，随意浪费Stack尺寸被证明是不明智的; 基于Heap的Buffer，优点是大小可以随需要而变，但缺点是其生命周期管理麻烦，容易出现Memory Leak，当其被用作模块之间的接口参数时，更使这种情况恶化。我们知道，C风格的函数在填充一个目标Buffer时，总要求调用者指定将被填充的Buffer，并指明Buffer尺寸，但调用者经常并不知道究竟需要多大的Buffer，一种改变（很难说是改进），就象Microsoft在其组件技术COM中采用的内存管理那样， 完全放弃Stack Buffer，将所有接口Buffer（即用作函数参数的Buffer）都分配在Heap上，并总由被调用的函数分配，而由调用者负责释放，显然，这只是一个简单但并非很合理的方案。本博主通过buffer_tt实践另外一种折衷的方案，基本思路是：调用者仍然象调用C风格的函数那样指定一个适当大小的接收Buffer，但不同的是，如果被调用者发现这个Buffer不够大，它会重分配足够大的Buffer用于填充，buffer_tt被设计用于正确管理所有这些情况，另外，提供一些用于Buffer填充的增强操作