项目计划

41 views
Skip to first unread message
Message has been deleted

klzgrad

unread,
Mar 11, 2010, 9:54:15 PM3/11/10
to scholarz...@googlegroups.com
欢迎各位加入西厢计划的开发。下面说一下我对此项目未来近期的想法和建议。

先规范一下命名。西厢是对一套东西的一个总体称呼,其中张某(ZHANG)指使客户端能够直连标准服务端的模块,崔某(CUI)指使标准客户端能够直连客户端的模块,gfw是指对GFW的伪包指纹进行匹配识别的模块。张某和崔某在逻辑上是客户端与服务端关系的良好比喻。这个项目在google
code叫scholarzhang是因为最初只有张某这一个模块,这是一种legacy的状况。

首先作为开发者,对于这个项目,应该消除幻觉,着眼缺点。西厢的弱点在README.wiki的局限一节已经描述得比较清楚,主要是两种问题:不稳定和易变。不稳定可能造成在使用过程中可能出现连接失败的情况,易变可能造成GFW升级之后如果西厢不升级便无法使用。不稳定是由于张某和崔某实际上做的是通过协议hacking弥补GFW造成的破坏,要求一种RFC规定的理想状况,原理就是不稳定的;而西厢的原理部分所依赖的GFW指纹和漏洞机制是易变的,需要即时更新。因此,“没有银弹”,西厢也不是对GFW的银弹,我看到自由亚洲的报道夸大其事,我想开发者关注的应该是bug才对。

然后,我想各位应该对西厢的工作原理有所理解。用wireshark就可以看到西厢做了什么,背后的原理首先应该看RFC793和README.wiki引用的那篇论文,其次可以看gfw技术评论的几篇文章。如果还不明白,过一阵我再发一点资料出来。

然后就是关于西厢的开发。我想强调一下所谓alpha状态的含义,就是目前这个东西本身可以用,但是具有强烈的试验性,扩展、用户支持等等特性都是没有的。由于原开发者已经没有时间继续开发,因此直接把alpha版作为prototype放了出来,希望抛砖引玉。我觉得这个项目并非一个结构特别紧密的项目,因此分支也不一定要组织特别严密,各自为战也会不错。

关于西厢本体,我觉得它目前有几个任务:
1. 测试。特别需要进一步测试明了issue #13提出的不稳定的状况,这应该是当前影响用户体验的主要问题;
2. 打包。用户如果能够直接运行dpkg
-i之类的一行命令就安装完毕,这比自行编译会方便许多。注意到西厢目前涉及到内核模块编译,我建议在打包中采用dkms框架,可以良好处理内核版本不同的问题。比如debian的virtualbox-ose-dkms便采用了dkms框架;
3. 移植。BSD系列用ipfw,跟iptables不一样。windows就更不一样了。当然这是一个显然的问题。

不少人提出西厢的分支任务,希望改成用户态的。张某原来也是用户态的,最后进入内核的原因在WhyNetfilter.wiki里面说明了,总结一下就是:优雅;iptables/ipset带来的高可配置性;性能。当然这也是原开发者的一己之见,西厢计划本身对于衍生项目不会有任何限制。如果要移植或者要改成用户态,那么就应该把易变的那部分业务逻辑抽象出来单独维护,其余各部分采用这个。

关于项目组织。首先欢迎大家认领自己感兴趣的部分(回复中说明),需要committer权限的向代码库管理员提出即可。其次是希望大家独立,西厢计划不是NED资助的组织,不用对我们期待过高。西厢的原开发小组即将解散,我们仍然会继续在原理部分提供帮助,但是由于能力和时间有限,我们基本上不会参与接下来的实际开发和项目领导(当然需要有基本的控制以免意外),如果有同学项目管理经验丰富可以来带头。

Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
0 new messages