我们知道，报文在网络上的流转主要是以二进制方式传输，而报文具体的含义依赖于收发双方的私有约定。而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的思路，具体定义将进一步在后续中描述。