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

通过网络相互通信的系统之间（如客户端与服务端的通信）要想正常交互，它们必须有“共同的语言”，这种语言就是消息协议。遵守消息协议的消息才能被我们的系统所理解。
我们知道，消息在网路上传输的是字节流，而我们主流的面向对象系统中处理的却是“对象”，如何将从网络上接收到的字节流转化为“对象”，又如何将“对象”转化为字节流以便通过网络传递给其他系统，这便是IContract接口定义的内容：

1 ///<summary>
2///IContract用于抽象通信协议格式的基础接口。
3///</summary>
4publicinterfaceIContract
5{
6void FillMyself(byte[]data,intoffset);//将流解析为对象
7int GetStreamLength();
8
9byte[]ToStream();//将对象转化为流
10voidToStream(byte[]buff,intoffset);
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 可复用的通信框架（序）