信令处理中IE机制的讨论.doc

IE机制的讨论目前的IE机制目前IE的操作比较简单, IE Buffer采用连续的空间, 需要事先分配, 大小固定. 提供的主要操作是Add和Find. 主要优点:机制简单, 出错机率小, 效率比较高, 控制比较灵活.主要缺点:容量不能动态改变, 操作前需要事先估算空间大小, Add操作目前没有保护.出现的问题在小批量(3CPS, 5CPS)的性能测试中, 当CSCF呼叫实例达到600左右时, 马上出现Heap内存分配失败, 呼叫无法继续(目前配置CSCF Heap内存为95M, 实际可动态分配大小73M), 而600个实例中有300个是P-CSCF订阅的实例, 同时由于P/I/S-CSCF在一个板上, 实际同时进行的呼叫也就是100个多一点, 系统性能十分低下.原因分析:1. IE机制问题: 由于IE Buffer不能动态改变, 在发送消息前需要分配所有可能的空间;2. CSCF和LEG之间的消息处理机制问题:a) LEG在收到USIP消息后, 分配足够大的空间(目前309600), 将SIP消息组成IE形式发给CSCF, CSCF再对该Buffer直接进行操作, 如增删, 移动等. b) CSCF在通过LEG发送任何响应消息(包括NXX, BYE, CANCEL等)时, 都需要分配一个足够大(目前309600)的IE Buffer, 构造成LEG需要的形式发送到LEG层.导致一个呼叫可能同时占住几个300k的空间.而事实上, 根据Abel的测试, 在以上的case下, 309600空间的实际利用情况如下:# SND_MSG_LEN_STAT begin #gStatOnSndMsgLen 0= 7422, occupy: 12%gStatOnSndMsgLen 1= 1290, occupy: 2%gStatOnSndMsgLen 2= 7148, occupy: 11%gStatOnSndMsgLen 3= 1946, occupy: 3%gStatOnSndMsgLen 4= 3246, occupy: 5%gStatOnSndMsgLen 5= 6839, occupy: 11%gStatOnSndMsgLen 6= 3572, occupy: 5%gStatOnSndMsgLen 7= 5207, occupy: 8%gStatOnSndMsgLen 8= 2916, occupy: 4%gStatOnSndMsgLen 9= 1296, occupy: 2%gStatOnSndMsgLen10= 2588, occupy: 4%gStatOnSndMsgLen11= 971, occupy: 1%gStatOnSndMsgLen12= 971, occupy: 1%gStatOnSndMsgLen13= 1617, occupy: 2%gStatOnSndMsgLen14= 1617, occupy: 2%gStatOnSndMsgLen15= 2262, occupy: 3%gStatOnSndMsgLen16= 2911, occupy: 4%gStatOnSndMsgLen17= 1621, occupy: 2%gStatOnSndMsgLen18= 1296, occupy: 2%gStatOnSndMsgLen19= 1298, occupy: 2%gStatOnSndMsgLen20= 1296, occupy: 2%gStatOnSndMsgLen21= 974, occupy: 1%gStatOnSndMsgLen22= 0, occupy: 0%gStatOnSndMsgLen23= 325, occupy: 0%gStatOnSndMsgLen24= 0, occupy: 0%gStatOnSndMsgLen25= 0, occupy: 0%gStatOnSndMsgLen26= 0, occupy: 0%gStatOnSndMsgLen27= 0, occupy: 0%gStatOnSndMsgLen28= 0, occupy: 0%gStatOnSndMsgLen29= 0, occupy: 0%gStatOnSndMsgLen30= 0, occupy: 0%gStatOnSndMsgLen31= 0, occupy: 0%# SND_MSG_LEN_STAT end #其中数组下标代表了10K的个数. 大部分都是100k以下, 因此造成极大的浪费.解决方法讨论根据以上的分析, 有以下两个解决途径:1. 修改IE机制, 使得可以根据需要动态扩展所需要的Buffer大小, 这样就可以事先分配一个合适的大小, 然后再自动调整;2. 修改CSCF/LEG层之间的消息处理机制.第二种途径目前没有很好的解决方法, 可以提出来讨论.针对第一个解决的途径, 经过几次讨论, 结合实际应用的情况, 提出了以下的具体解决方法:1. 采用分段机制, 初始大小暂定为100K;2. 在首块Buffer的起始位置放置一个控制头域, 用于保存各分段的地址, 大小及其他控制信息, 内容如下: #define OAM_MAX_IE_SEG 10 #define IE_BUFFER_LEN 100*1024 #define IE_BUFFER_INC 50*1024 typedef struct unsigned int pSegAddr; unsigned int nSegSize; IeSegHead; typedef struct IeSegHead pIeBuffSegOAM_MAX_IE_SEG; /* IE Buffer Block information */ unsigned int nCurrSeg; /* Current operation segment no */ unsigned int *pCurrAddr; /* Current write address */ IeBufHead;3. 增加一个IE: IE_SEGMENT, 用于分段. 在IE_add时, 判断到当前块的剩余大小不够时, 加入IE_SEGMENT, 内容指向新分配的块地址;4. 目前IE操作的API参数及调用方式基本不变: U8 *IE_find(U16 ieTag, U8 *pHead, U32 dwLen,U32 *pIeLen); U8 *IE_add(U16 ieTag, U32 wLen, U8 *pSrc, U8 *pDest, U32 *pIeHead); U8 IE_rmv(U16 ieTag, U8 *pBuffOrgn, U32 *pBuffLen); U32 IE_copy(U8 *IeBufOrig, U8 *IeBufDest); 其中IE_add的最后一个参数目前没用, 改为IE Buffer的首地址.5. IE Buffer的分配和释放由OAM提供专门的API: U8 *OAMAllocIEBuff(U32 size); U32 OAMFreeIEBuf(U8 *IeBufOrig); 首片Buffer大小可以指定, 默认为100K. buffer中头域对应用不可见, 返回的地址直接指向真正的IE Buffer. Bu