结构和网络字节流的转换方法

做服务端软件久了，就在思考一个问题。我们使用C++和JAVA作为开发语言，经常要面临一个问题，要将结构或者JAVA类序列化成网络字节流。这里面涉及到，字节对齐，字节序，报文边界等一些问题。JAVA本身就有序列化和反序列化机制，但是C++没有。

大概看了下JAVA的序列化本身，发现他包含很多创建相关的信息，实际上，网络上的流不但包含了纯粹的数据，还包含了数据操作的行为。个人认为，这在对性能要求比较苛刻的环境中，比如行情，游戏中，是无法接受的。但JAVA本身创建的理念就是要在没有本地缓存以及跨平台的环境下也能够运行。那么这个序列化的方法，反而可以理解。

我曾经在自己的博客中《简单报文 》提到GEST协议，这个协议纯粹是负责数据的传输，和数据的描述，不涉及对数据的操作。他的亮点有这么几个：

1、与语言无关，只是纯粹的流数据。

2、具有动态的结构描述功能。动态的结构描述功能，通常只出现在数据库这类，没有固定输入和输出的应用，或者XML进行不同系统之间的数据交换。GEST以自描述的方式，作为架构的基础。

3、协商机制。对于绝大多数的应用来说，在C/S双方来说，传输的数据结构是固定。因此，对于固定结构的数据，可以协商之后，以特定代码表示这类数据。这种场景，是最普遍。在网络上传输的数据是最小的，同时又能保证本地是可以还原出来。

4、嵌套结构。对绝大部分的应用来说，类似数据库那样的表格数据完全足够了，但是，有些数据是被嵌套的。某种类型的数据结构被嵌入另外一个结构之内。

但是，缺点也同样不少。

1、需要会话支持。协商机制只会存在于会话中，没有会话作为基础，协商是没有意义的。

2、不支持对数据的操作。如何操作数据，必须是C/S双方已经定义好了。

 

在一些已经固定应用中，如交易所的行情，存在一种叫做FAST协议的。他还能够依靠上下文中间的关系，传输增量的变化。根据测试，系统的压缩率可以高达70%－80%。而，GEST协议，还少了结构描述信息，在这种应用场景中，能够提供更高的压缩率。当然，这是在特定的环境中。在更大应用范围，依然能够提供足够好的自描述机制和压缩率。