发布一个协议, STMP(Simple Transaction Management Protocol) (一)

发布一个协议,名字起的比较响亮,叫做STMP(SimpleTransaction Managment Protocol), 即简单事务管理协议. 协议是ITU-T Q.773的一个变种,也就是七号信令中的 TCAP 协议,TCAP是一个古老的协议,似乎是出现在上个世纪80年代末,一直在GSM核心网的一些网元中担负着各类信令流程的事务控制与处理.通常以下面的协议栈类型出现:

MAP

TCAP

SCCP

MTP/M3UA

对于非从事通信行业的同学而言,TCAP更简单的描述是:每次用手机发送短信,拨打电话,都会触发一系列的TCAP协议报文, 短信内容亦基于TCAP承载, 可见其重要性.TCAP协议本身具有抽象能力强,语义表达准确,易读,低冗余,可扩展,天然的支持二进制,高性能等特性.

说到易读,可扩展,最容易让人想到的是xml和后起的json,这两种协议(语言)都具强大的业务抽象能力,天然的可读性,入门非常容易.xml作为配置文件使用时,比起ini来更让人觉得优美无比.json则可能具有更低的冗余.但这种两协议在作为通信协议使用时,在我个人看来,至少有三个硬伤,其一是,冗余太高.其二,不支持二进制,其三,协议编解码成本偏高.在性能和带宽敏感的通信场景中,使用这两种协议绝不是好的方案. 

STMP协议继承TCAP的部分优点和缺点,并作了一些改变,可以描述成下面几点:

继承的优点:

1.事务部分设计,STMP作了少量扩展.

2.信元设计,构造体和简单体作了少量改动.

3.信元的长度字段作了少量改动,延缓冗余的可能.

4.抛弃了不定长的信元设计,及某些可能无意义或很难用到的东西.

继承的缺点:

1.支持二进制的协议当然没有xml和json那么易读.但STMP协议还是很易读的,前提是你必需对二进制和十六进制比较熟练.事实上,在日常开发调试阶段,辅之以日志方式进行输出,就算你抗拒十六进制,读起来还是赏心悦目的.

2.如果你想在某些二进制不友好的语言中操作STMP报文,可能会很别扭.

3.协议编解码可能稍复杂.

STMP是一个面向消息的协议,本身不负责报文的有序与可靠性.

STMP只定义了少量的基本信元(InformationElement),用于事务处理.

STMP不定义使用的协议栈,你可以在TCP,UDP/RUDP, SCTP, HTTP等协议上承载它.

STMP目标使用场景至少包括: RPC, IM即时通信, 网络游戏等, 尤其适用于对流量敏感的手游.

下面将描述STMP的部分细节, 随后的博文将继续补充.

1.TLV信元设计

             TLV即tag-length-value的首字母缩写,它是STMP协议的基本组成部分和核心.

             a).tag, STMP定义两种类型的tag,即构造体(construct)和简单体(primitive),简单体是一个不可再分割的TLV结构,而构造体的value部分则可能是另一个TLV的开始,

             这是一个递归的表象.二者在报文上的区别体现在tag的首字节的G位,G位为1时,为构造体, G位为0时,为简单体.如下:

                                                                  H  G  F  E    D  C  B  A

                                                                  0   1  0  0     0  0  0  0    /** 构造体.*/

                                                                  0   0  0  0     0  0  0  0    /** 简单体.*/

              tag值可以是一个或两个字节,因此,STMP最多可以有0x10000个tag值,也就是65536个,例:

                                                               0x60(01100000)是一个构造体,0x20(0010 0000)则是一个简单体.

              至于tag是占用一个字节,还是两个字节,由首字节最高位H位表示,H位为1时,tag值为两个字节, 否则为1个字节,例:

                                                               0x8080(10000000, 1000, 0000)是一个双字节的简单体tag.

                                                               0xC010(11000000, 0001, 0000)是一个双字节的构造体tag.

              b).length, length字段可以是1个,3个,或5个字节,用于描述不同的value长度.包括 uchar(0xFF),ushort(0xFFFF)和uint(0xFFFFFFFF),使用下面的规则:

                         1.当value长度小于0xFD时,length字段本身即为value的实际长度,因此,单字节length 的tlv最多可携带0xFD,也就是253个字节.

                         2.当value长度大于0xFD时,length字段的首字节应该只有两种可能的取值,即0xFE和 0xFF,前者表示除首字节外,length字段还有两个字节用于表示value的长

                          度.后者表示除首 字节外,还有四个字节用于表示value的长度.双字节或四字节使用网络字节序(即大头在前). 例:

                                                                0xFB是一个单字节的length.

                                                                0xFE 0x01 0x00则是一个三字节的length,实际的value长度是0x0100.

                                                                0xFF 0x00 0x01 0x00 0x00, 则是一个五字节的length,实际的value长度是0x00010000.

               c).value, value字段是信元内容,可以是一段正文,可以是另一个TLV的起始,亦可以为空.

2.事务部分设计

事务处理层定义了七种会话原语和一对事务ID,用于标识通信双方各自的事务,即源事务ID(sourcetransaction ID)和目的事务ID(destination transaction ID),如下:

事务原语	原语描述	tag值	源事务ID(STID)	目的事务ID(DTID)
BEGIN	事务开始,由事务发起方发出	0x60	有	无
END	事务结束,通信双方均可结束	0x61	无	有
CONTINUE	事务继续,通信双方均可继续	0x62	有	有
SWITCH	前转/交换事务,未使用	0x63	-	-
ABORT	中断事务,通信双方均可中断	0x64	无	有
CANCEL	取消事务,发起方取消	0x65	有	无
UNI	单向消息,无事务关联	0x66	无	无

源事务ID和目的事务ID原则上(应该/可能)是一个整数,tag值定义在下表:

源事务ID(STID)	0x00
目的事务ID(DTID)	0x01

3.业务/操作层设计

由具体业务按STMP协议的TLV规范自行定义, 可以理解为从这里开始定义常说的CMD(命令字).

4.一个可能的STMP报文样式.

5. STMP协议的c语言快速实现, 稍晚再奉上java的实现.

http://download.csdn.net/detail/u011828940/6019181