Size: 3932
Comment:
|
Size: 3934
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 44: | Line 44: |
===XML描述文件结构=== | === XML描述文件结构 === |
系统说明书 文章模板
Otter Tool系统说明
-- hd [DateTime(2004-08-14T22:48:06Z)] TableOfContents
系统概述
Otter Tool是一个代码自动生成工具,它通过解析一个描述我们所需协议的XML文件来自动生成我们这个协议的Python代码,这样我们为Otter Base添加一个新的协议的时候,只需要把协议的XML描述文件填好,然后运行一下Otter tool,一切就出现在眼前了:P--just filling and running
它将我们从代码的重复工作中解脱出来,让基于二进制流协议的开发更为简单,让开发人员更关注于业务逻辑而不是基础的twisted、窗口这些复杂的事务。
系统功能
Otter tool完成以下几项工作:
- 解析协议的XML描述文件
- 将从XML解析出来的数据结合模板填充成我们所需的Otter代码
而实际上我们真正需要做的工作就是:
- 按otter tools的规范填写XML文件
- 运行Otter tool生成相关代码
- 写你的服务器和客户端的业务逻辑罢
系统处理流程
在运行Otter Tool程序的时候我们需要输入一个协议的XML描述文件,Otter tool通过解析这个XML文件,调用预制的Python代码模板,填充后生成出这个协议的四个Python代码文件。它们分别是:
- *pmsg.py 消息定义
- *p.py 协议定义
- *c.py 服务器端定义
- *s.py 客户端定义
*号代表协议的名称。
这四个文件中,*msg.py是对协议的报文格式进行定义的,*p.py是对协议的传送协议进行定义的,*c.py是该协议的客户端,*s.py是该协议的服务器端。
在对新协议进行开发的时候,我们需要在XML文件中对协议的各个部分进行描述,运行Otter tool生成上述四个文件。*msg.py和*p.py是协议的定义文件,我们不需要再改动它们。对新功能的扩展,我们通过扩展*c.py和*s.py来完成。
系统静态结构和动态结构
系统静态结构
Otter tool的静态结构分为三个部分,两个输入结构,一个输出结构。
XML描述文件结构
首先是XML描述文件的结构,其定义如下:
attachment:040816-otter-00.jpg
根元素为<Otter>,它有三个属性,分别为:
属性名 |
类型 |
状态 |
说明 |
Version |
字符串 |
必须 |
标明协议的版本号 |
PersistentConnection |
布尔值 |
必须 |
是否为长连接协议 |
ProtocolName |
字符串 |
必须 |
协议名称。生成的协议代码将会存放在以次命名的子目录中 |
子元素有两个,分别为<Message>和<Protocol>
<Message>属性:
属性名 |
类型 |
状态 |
说明 |
默认值 |
MessageName |
字符串 |
可选 |
指定报文定义代码的名称 |
协议名+pmsg.py |
MessageHeadClass |
字符串 |
可选 |
报文头定义需继承的类 |
bytemsg.ByteMessageHead |
MessageBodyClass |
字符串 |
可选 |
报文体定义需继承的类 |
bytemsg.ByteMessageBody |
<Protocol>属性:
属性名 |
类型 |
状态 |
说明 |
默认值 |
ProtocolName |
字符串 |
可选 |
传送协议代码的名称 |
协议名+p.py |
LisetenPort |
整型 |
必须 |
传送协议使用的端口 |
<Message>有两个子元素,<Commands>和<MessageHead>。<Commands>元素负责描述报文中的命令列表,<MessageHead>元素负责描述报文头中包括那些内容。这两个元素没有属性。
<Commands>元素包含一个子元素<Command>,负责描述每个报文的命令。 <Command>属性:
属性名 |
类型 |
状态 |
说明 |
CommandName |
字符串 |
必须 |
定义命令的名称 |
CommandID |
字符串 |
必须 |
定义命令的ID |
第二是代码模板的结构其内容为:
第三是输出的代码
系统动态结构
系统模块及结构