ESFramework介绍之（1）――网络通信消息协议接

1 /// <summary>
2 /// IContract用于抽象通信协议格式的基础接口。
3 /// </summary>
4 public interface IContract
5 {
6 void FillMyself( byte []data, int offset); // 将流解析为对象
7 int GetStreamLength();
8
9 byte []ToStream(); // 将对象转化为流
10 void ToStream( byte []buff, int offset);
11 }

IContract 接口中的各个成员的意思非常的清楚，含有 offset 参数的重载 ToStream 方法（第 10 行）可以将转化的结果流写到指定的 buff 中，这个方法是必须的，否则就会遇到很多需要拷贝缓冲区的操作，这将严重的损害运行的效率。

很多朋友一定想到了， .NET 中将对象转化为字节流或将流转化为对象的最方便的方式就是使用 “ 序列化 ” ，是的，如果各个通信的系统都是基于 .NET 平台创建的，当然没有问题，这种情况下，使用 .NET Remoting 可能会更好（使用 Remoting 可以完全省略对消息协议的关心，因为 Remoting 已经帮你打点好了一切）。但是更多的情况是，相互通信的系统是异构的。比如，服务端是 .NET 平台，而客户端却是 PDA 上 C++ 写的程序，遇到这种情形， .NET 的序列化、 Remoting 就无能为力了，我们必须自己手动打理一切。你也许会说，可以使用 WebService ？呵呵，好了， ESFramework 主要关注的是构建基于 Tcp 或 Udp 网络系统，至于什么情况下，该使用 WebService 还是该直接在更低层的 TCP/UDP 上构建系统的问题，还是留待读者自己去思考吧：）

如果不能使用 .NET 的 “ 序列化 ” ，那么常用的是什么方法来完成 “ 字节流《＝》消息对象 ” 的转换了，即 IContract.FillMyself 和 IContract.ToStream 的实现方式是什么？一个字节一个字节的处理。比如，我们消息协议中规定，接收到的字节流的前四个字节是一个使用 UTF8 编码的字符串 “@@@@” ，那么，我们解析时，就用 UTF8 来将接收到的前 4 个字节解析为字符串 “@@@@” 。接下来的 4 个字节是一个整数，那么你可以使用 BitConverter 类来将这四个字节解析为一个整数， ...... 如此，一直将所有字节流解析完毕，生成一个完整的 “ 消息对象 ” 。至于字节流中的第几个字节放什么内容，那是你的构建应用时必须定义好的－－消息协议。所有的消息协议都实现 IContract 接口。在此基础之上，应用系统才可以在不了解协议内部细节的情况下，对所有的消息进行统一的处理（这就是 “ 多态 ” 的应用啊），如此才有可能实现系统运行中动态加载功能插件的能力。

ESFramework 是一个框架，它不关注你具体应用中的具体消息协议，它只关注 IContract 接口，这样 ESFramework 框架才可以在不同的应用中复用。如果要使 ESFramework 框架帮助我们构建应用时更加容易， ESFramework 就需要把我们应用中更多共性提取出来，那么它必须 “ 标准化 ” 更多的东西， IContract 只是其中的一个。接下来的文章中你会看到 NetMessage 的引入，系统之间通过网络交互的消息都可以表示成 NetMessage ，并且 NetMessage 游走于系统内部的各处理器、钩子 Hook 之间，正是由于这种前后一致性，使得 NetMessage 成为 ESFramework 的核心要素之一，关于 NetMessage 的具体介绍请留意下篇文章：
ESFramework 介绍之（ 2 ）――网络通信消息 NetMessage

转到： ESFramework 可复用的通信框架（序）