单一世界【3】简单报文

我们知道，报文在网络上的流转主要是以二进制方式传输，而报文具体的含义依赖于收发双方的私有约定。而XML设计于一种通用标准，在业务上具有更广泛的适用性，但其解析上有较高的复杂度，带来性能损失。我们需要设计一种高效、简单、更强业务描述能力的报文协议，显然，在报文定义具体业务含义的内容是不可行的。我将这个报文协议命名为GEST协议，全称是A GENERAL 、 EFFICIENT 、SIMPLE TRANSFER PROTOCOL。

第一，我们以数据库、IM、游戏等占大多数应用的报文为考察目标。我们会发现，所有的业务级数据通常可以分为2种结构，表格与树。表格以数据库为典型，C类型的结构也可以表述为只有一个纪录的表，而变量则退化为只有一个字段的表格。而更复杂的，在表格中嵌套表格，实际上，也是树的一种表达方式。

第二，我们要考虑如何表述表格和树。如何在报文中描述表格以及内容相对比较简单，只要在报文中包含每个字段的名称以及值的类型就可以，而表格的纪录则共享相同的字段定义。不过，还要考虑的是，如果在一个报文中，包含多个表格。树的表述可以从表格进行扩展，我们可以定义一个特定的字段，指示子节点是一个表格，而该表格的定义可以放在其他地方。如果一个报文中包含了多颗树，可以参考多个表格的组织结构。由于一个棵树的定义包含了多个表格，那么数据存储同样按多个表格保存，通过外部关键字进行关联。

第三，我们要考虑如何减少传输信息。表格的定义信息是个不小的数据，包括字段名，字段长度，字段类型信息等。如果每次都传输这些信息，会造成很大的网络传输负荷，因此需要提供一种方式，能够通过标记查询某个ID的结构定义，从而为后续的传输来复用。这种方式在数据库中不大好用，因为每次的结果集定义都不同，不过大多数的定义是固定的，比如魔兽世界，每个操作码对应的报文结构是固定的。

第四，长度信息在很多地方被用到，但大多数情况下，只要1到2个字节，而不是4个字节，因此7BITS的压缩方法将被使用。而象GUID这些稀疏大值，用位图的方式压缩是个不错的主意。2者的区别在于7BITS适用于小值的情况，而位图适用于稀疏大值的情况。

第四、采用压缩流也是个减少传输量的手段，比如象JABBERD那样，支持压缩XML流。协议本身不能对具体实现方式作出规定，因此，最多只能提供多种选择项。由于报文的定义，提供了多个表格拼接一个报文的可能，为成组传输提供可能，能有效降低交互次数。

第五，由于所有的数据都是表格化的，对数据的解析要简单很多，跟XML相比要快很多。即使是嵌套的情况，解析出表格数据后，也能很快还原出树结构。

 

GES协议：

struct head{

    uint16  magic  ;   //魔数

    uint16  len ;        //整个报文长度

    uint8   version ;   //报文版本

    uint8   type ;      //报文类型

    uint8   tcount ;   //表格定义数量

    uint8   flag ;       //标志位

    uint32  serial ;    //报文序列号

} ;

 

struct field{

    uint16 type ;        //字段类型，数值，字符...

    uint16 field_len ;   //字段值的长度

    uint8 name_len ;   //字段名称长度

    char name[256] ;  //名称字符串，变长

    uint16 nest_index ;      //嵌套表的索引，type为嵌套时才有效

    uint8   precise ;    //浮点精度

    uint8   decimal ;   //小数点后几位

} ;

 

struct table{

    uint32    guid ;     //表格定义的唯一标记

    uint8  name_len ;  //名称长度

    char name[256] ;  //名称

 

    uint8    field_count ;//字段数量

    struct field fields[256]   //字段定义

 

    uint32  record_count ;  //记录数

} ;

 

struct nest{

    uint32  guid ;             //本身的唯一标记

    uint32  key  ;            //嵌套表中的值

} ;

 

 

这个定义只是大体描述了GEST的思路，具体定义将进一步在后续中描述。