ESFramwork详解.docVIP

ESFramework介绍ESFramework介绍之（1）――网络通信消息协议接口IContract通过网络相互通信的系统之间（如客户端与服务端的通信）要想正常交互，它们必须有“共同的语言”，这种语言就是消息协议。遵守消息协议的消息才能被我们的系统所理解。 我们知道，消息在网路上传输的是字节流，而我们主流的面向对象系统中处理的却是“对象”，如何将从网络上接收到的字节流转化为“对象”，又如何将“对象”转化为字节流以便通过网络传递给其他系统，这便是IContract接口定义的内容 ///summary ///IContract用于抽象通信协议格式的基础接口。 ////summary Public interface IContract { void FillMyself(byte[]data,int ffset)//将流解析为对象 int GetStreamLength()byte[]ToStream();//将对象转化为流 void ToStream(byte[] buff,int ffset);} IContract接口中的各个成员的意思非常的清楚，含有offset参数的重载ToStream方法可以将转化的结果流写到指定的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的具体介绍请留意下篇文章： SFramework介绍之（2）――网络通信消息NetMessage较之C++而言，.NET是一个更加“动态”的平台，其动态能力建立在反射机制之上，而反射的基础是“元数据”。 ??? 上文已经提到过，如果一个框架要为我们的应用做更多的事情，那么这个框架必须建立更多的标准，必须对框架自己要处理的消息有更多的了解，所以，每个消息都要是自描述的，也就是说每个消息要包含它自己的“元数据”。那么，“元数据”位于消息的何处了？你一定想到了，对，是消息头（MessagHeader）。 ??? 在ESFramework中，消息NetMessage由“消息头+主体”构成，并且消息头和主体都必须实现上文讲