系统说明书 文章模板
系统说明标题
-- Jerry Marx [2004-09-06 01:45:07]
1. 040918 讨论
讨论录音,hd 还解答了 xyb 提出的19个问题。
2. 040917 讨论
今天基本放空. 下面列出小谢给的一些相关资料页面
3. 040916 讨论
讨论内容已经由Xie yanbo发到 "mail list"
关于Mock Object的讨论. 以下是一些资源
Xie yanbo正式出任unit test子项目负责人
Xie yanbo向HD提出17个关于compass的问题,期待HD在maillist回答.
3.1. 040916 Xie yanbo
单元测试公用模块,用来创建测试环境等
单元测试样例,可以作为模板使用
单元测试约定,比如一些特殊对象应该怎么用,主要是用来使大家分别编写的单元测试可以放在一起使用,就象twist单元测试文档中的建议的那些。
4. 040915 讨论
放空!中午 Jerry 没有出现在MSN 或是大家都直接UC 了!??!
Zoomq 当前整理时没有收到昨天录音的信息,今天……
WCstory -- Woodpecker.Compass 用户故事!
嗬嗬嗬!缩写的确是 W.C 实在!!! 又有重名的事儿!还是赶紧想法子哪!
5. 040914 讨论
am HD在线从MSN 移动到UC 中进行详细讲解
录音整理后发布
5.1. Zoom.Quiet
重新整理类设计关系图
6. 040913 讨论
6.1. Zoom.Quiet
总结UML图和讨论为Compass调用结构关系图
6.2. Xie yanbo 9月13日
“compass的server会以守护进程的方式运行在中心服务器上,当然实际 系统分布为了避免单点故障问题不会只有一台中心服务器,但是服务器的 冗余是放在四层或者七层交换的后面,对于我们开发人员来说是透明的, 所以在开发者的角度看我们只需要处理一个中心服器.
“compass的client会以守护进程的方式运行在运行网络服务的的各台 服务器上.为服务提供一个API使得服务可以注册/注销自己或者查询需要 的其他服务器,然后由compass client和compass server交互.”
我想这里的 Server、Client 的概念已经和我们平常所熟知的概念很不 一样了,根据 Twisted 编程规范之命名原则:
我们应该给 Compass Server 和 Compass Client 重新起名。按照我的 理解,建议如下命名:
Compass Server => Service.Dispatcher 调度员服务
Compass Client => Service.Agent 中介者服务
7. Jerry Marx 9月6日
由于我自己机器的问题,我一直不能在UC上发言.我有一些想法我就发在列表里面了,免得集中起来的时候浪费大家的时间
第一个要通报的消息就是compass(指南针)这个项目要启动了.项目的主页在这里: http://wiki.woodpecker.org.cn/moin.cgi/Compass
当然目前还处在前期的准备工作阶段. 目前的工作我想主要有以下几个:
Twisted相关文档的翻译和学习.
其中优先级最高的是以下几章: Tutorial(这部分翻译工作已经完成) http://wiki.woodpecker.org.cn/moin.cgi/TwistedTUT
Low-Level Networking and Event Loop(这部分翻译快要完成,由Jerry [email protected] 负责) http://wiki.woodpecker.org.cn/moin.cgi/PyTwisted_2fLowLevelNetworkingEventLoop
High-Level Twisted(这部分由令狐虫 [email protected] 负责) http://wiki.woodpecker.org.cn/moin.cgi/PyTwisted_2fHighLevelTwisted
Working on the Twisted Code Base(这部分由BigBaboo [email protected] 负责) http://wiki.woodpecker.org.cn/moin.cgi/PyTwisted_2fWorkingOnTheTwistedCodeBase
Utilities(这部分由Jerry [email protected] 负责)
当然欢迎大家参与,为了避免重复劳动,参与翻译的时候可以先和相关负责人联系. Twisted的原文在安装了Twisted后就可以在本地浏览 开始 -> 程序 -> Twisted -> manual 或者在这个地址: http://twistedmatrix.com/documents/current/howto/
对于Outter的学习
compass是基于Twisted的网络应用,当然要用到Outter.基本框架应该就是用Outter来生成了. 这方面还需要Outter组的大力支持
对于compass的理解和认识
这个就不多说了.开发人员必须对于系统的理解达成一致以后才能协调开发.这方面还需要多交流.
我先说说我对于compass的认识吧
首先compass的第一个目标就是为OpenUSS服务,提供服务注册/查找/注销/依赖关系...等等的支持.
compass系统是一个分布式的,由一系列运行在各个服务器上的守护进程组成.其中包括一个中心的server和一系列的client.server和client的交互回采用推/拉两种方式,力图使网络负载最小化.
compass的server会以守护进程的方式运行在中心服务器上,当然实际系统分布为了避免单点故障问题不会只有一台中心服务器,但是服务器的冗余是放在四层或者七层交换的后面,对于我们开发人员来说是透明的,所以在开发者的角度看我们只需要处理一个中心服务器.
compass的client会以守护进程的方式运行在运行网络服务的的各台服务器上.为服务提供一个API使得服务可以注册/注销自己或者查询需要的其他服务器,然后由compass client和compass server交互.
服务数据库当然是由server来维护,但是为了避免server负载过重,也许只会把server设计为一个路过者而将具体的数据库管理再委托给另外的进程(也许运行在另一台机器上),不过这个对于client来说是透明的.
上面只是我自己的一点很粗浅的认识,希望大家指正.
8. 梅劲松 11月18日
我在compass上已经建立了多个应用,而且目前也在帮助和建议朋友使用compass来进行一些关键应用的开发。针对目前compass的使用,我提出以下建议。
1、服务器端是否需要流量控制
我的意见是在服务器端不考虑流量控制,至少在目前阶段不考虑。我们采用的滑动窗口的办法,对系统资源的消耗还是比较大的。而且我们的服务都是建立在相对封闭的环境下。
2、报文格式的修改
我建议在报文头上加上2个字节的状态码。目的是在compass解包的时候,在这一层就判断比如报文长度和声明是否相符,是否发送同一流水号的报文等。从而将和socket的通讯层的处理和错误隐蔽起来,这样compass的使用者只需要考虑和业务相关的报文内容和报文字段。
3、参考资料
我建议对协议、异步通讯、滑动窗口、GNS的理解有疑问的,参考中国移动的CMPP2.0或者CMPP3.0的协议资料。
4、具体的例子
任何事物都是发展的,我想我们需要先建立一个compass的原型。能满足compass的绝大部分功能,才谈得上优化和修改。我会提交部分代码上来,质量可能不是很高。希望比我更有经验的朋友进行优化。