很早以前就有打算要写个Python读取native.db（不知道这个的请G之）中联系人，短信的程序，不过没能成功，这两天又接触到了bsddb，于是今天分析了下这个native.db，没想到原来挺简单的。Berkeley DB本来就是一个很简单的数据库，只是在E680中系统把多个数据库同时存放在了一个文件中native.db，所以不可以直接使用bsddb.btopen来直接打开这个文件。由于Berkeley DB中只是一种类似Python中dict的数据库（key=value）所以要存放手机联系人（有很多字段，如地址，电话...），就需要使用多个数据库，然后每个数据库使用索引来与其它数据库建立联系。按照一般的想法应该是多个数据库的key是作为索引，然后value分别存放各种信息，但E680中的native.db恰好相反。

其实这样的结构也是很简单的，但是我在写代码的时候遇到一个问题，从某个数据库中读取一个key，然后使用bsddb中的get方法去取这个key对应的value，结果确是None，以前好像就是卡在了这一块，似乎与这个value的值有关系，这个value是二进制数据：“< x03x00x00”，不理解为什么这里不直接用整数作为索引而用这么奇怪的数据，或者这里是某种编码？

先不理这个，不管这个value是什么，使用sorted把每个数据库按照其value排序,下面是所有代码:

读取E680联系人:

xylftp服务器端经过了长期测试和修复，现在已经基本完善和稳定。我们宣布正式发布我们的第一个版本供大家使用！

a) 下载：

xylftp项目的的主页在：

https://sourceforge.net/projects/xylftp

xylftp服务器端1.0版本可以在这里下载：

xylftp-server-1.0.tar.gz

b) 安装：

安装方法：用命令 tar -xvzf xylftp-server-1.0.tar.gz解压，然后进入文件目录
xylftp/server/src/，运行”make install”命令即可完成安装。

c) 卸载：

卸载方法：进入文件目录 xylftp/client/src/，运行”make uninstall”命令即可完成
软件卸载。

d) 开发：

xylftp的CVS在：

http://xylftp.cvs.sourceforge.net/

截止目前，服务器端C代码总量为2400行。参与服务器端编写的人员有：

1.董溥：完成守护进程的建立，socket连接以及写日志，实现主程序的流程。
2.郭拓：完成do_list命令。
3.贾孟树：完成parse_cmd.c,telnet.c，以及do_quit命令，以及测试和维护工作。
4.林峰：完成配置文件的解析，完成do_user,do_pass命令,参与do_syst,do_type,do_noop命令以及测试和维护工作。
5.刘伟：完成do_pwd,do_cdup,do_cwd,do_rnfr,do_rnto,do_port命令。
6.刘洋：完成do_stat，do_mode,do_fail命令,以及测试和维护工作。
7.聂海海：完成do_retr,do_mkd,do_rmd,do_dele命令。
8.王聪：完成do_stru命令,完成Makefile编写,并维护了王老师的三个命令以及整个流程的测试和维护工作。
9.王亚刚老师：完成do_abor,do_stor,do_pasv命令。

感谢各位参与！

欢迎大家测试使用，并把信息及时反馈给我们！
（错误报告请发送至xiyoulinux@googlegroups.com）

由于个人原因在编码阶段我做了很少的工作，在这里再次对所有的朋友说一声“对不起！”。一个学期了，终于有了结果，象刘洋同学说的“大家通过一起做一个项目，一起风雨走来，一起体味其中的酸甜苦辣”，不管怎么样，终究是走了过来，确实没有什么槛是过不去的！

安装socket套接的的工作原理把socket一套函数(socket,bind,listen,accept,connect)封装为三个函数：_listen,_accept,_connect。

_listen函数中首先使用socket创建一个套接字，因为是在本机监听，所以使用的地址就是本机的IP地址。然后使用bind把socket生成的socket_fd与本机的一个端口号绑定，这个端口号为_listen的唯一参数。最后使用listen开始监听，本函数返回一个文件描述符，也就是socket产生的文件描述符。

_accept函数中直接调用系统的accept函数阻塞自己，直到有客户请求就接受请求，并且返回一个connect_fd的文件描述符（由accept产生），该函数的参数为_listen返回的文件描述符。

_connect函数与_listen函数类似也是先使用socket创建一个套接字，不过这里使用的地址就是服务器的地址与端口号，而不是本机地址与端口，这两个由该函数的参数给出。接下来它就使用connect去连接指定服务器的端口。

在测试的时候发现了一个bug，_accept返回的值一直为0，昨天中午开始找了半天的时间也没有发现问题，最后无耐之下使用了全局变量，才使用整个程序能够正常运行，不过这样一来就没有达到我封装socket的目的，而且也没有找到bug的原因，今天中午继续查bug，结果发现即使我封装的_accept只有一行语句:
return accept(socket_fd,(struct sockaddr *)&client_addr,&len);
仍然出错，最后看了一下调用_accept那一块的代码，原来问题出在下面的代码：

35 if ((connect_fd = _accept(socket_fd,client) == -1)) {
36 exit(0);
37 }

竟然找了N长时间没有发现！

五一放完假我们似乎又停到了详细设计上，这又是一块难啃的骨头，因为是C语言编程，如果按照软件工程的规范来做，详细设置的时候定义好所有要用到的函数，包括参数，这样对于我们这些没接触过软件工程的人来说无疑是一个巨大的难题。这似乎是不可能的事情，等了两三天毫无进展。在周三的例会上，王老师提出了这个问题，建议我们详细设计与编码同时开始，本来我也打算提出这个建议，没想到王老师先说了:)

接下来我们就开始进行编码了，不过从这几天的情况来看并不是很乐观，有一个很大的问题就是沟通，也许是从也没有在一块试着多人合作写代码，在接口的处理上，一些常用功能的封装上存在着很大的问题。

经过了这段时间的煅炼，觉得一个人在团队中的合作精神确实是非常重要的，而一个既有技术，又有领导才能的人更是难得。

update1:删除了bind()参数，先前bind()参数使用了IP地址。
update2:使用刘洋同学画的那个，把处理的描述改为了中文描述，而不是一些不太清楚的函数，修改了初始化部分的顺序，最开始读取配置文件。

最后我修改了其中较明显的一些错误，添加了命令对应的返回码，并在配置文件中添加FTP使用的端口号，使用户可以自行配置FTP监听的端口号。

需求分析

我们是分两个小组来做服务端与客户端，服务端使用的是C语言，当然是在Linux下做了，客户端使用的是Java。我参加的是服务端的设计，因为对协议看的比较多些，上星期的时候讲了一下FTP工作的整个过程，做了一个PPT。

但是在服务器的具体socket处理方面还是不太清楚，今天下午和王聪讨论的时候逐渐把整个FTP socket一块的东西弄的清楚了很多，也有了今天晚上黑板上讲的一些东西，觉得两个人在一块讨论确实能够解决很多问题，而且能学到很多东西。

PPT下载
点击查看

1.1 编写目的

确定整个程序设计框架，以及需要实现的功能，对程序接口进行定义，定义运行状态以及出错处理。

1.2 背景

a.项目名称：xylFTP(待定)
b.
任务提出者：王老师
开发者：见软件需求说明书1.2.b
用户：服务端主要面向Linux用户，客户端面向所有可以使用JVM的用户。
中心：运行FTP服务器的机器

1.3 定义

JVM：java virtual machine
FTP：File Transfer Protocol

1.4 参考资料

a.软件需求说明书[url]http://wangcong.org/blog/?p=119[/url]
b.见软件需求说明书1.4

[b]二 总体设计[/b]

2.1 需求规定

a.输入：服务端需要配置文件xylftp.con，不接受其它参数输入。客户端接受从终端输入的命令，以及启动客户端所带参数。
-u $user 使用$user连接，当不使用-u时使用shell用户名连接。
-h [$command]显示客户端所允许的命令，$command指定的情况下显示$command相关使用方法。
-v 显示版本信息
-d 显示更多额外信息，供查错使用。
-a 自动登录，使用.xylftpauto.conf文件中包含的内容自动登录

b.输出：服务端在运行过程中产生文件xylftp.log，收集一些客户端连接信息，包括登录时间，IP，下载、上传文件、数据量，以及断线时间。客户端响应终端输入显示帮助，以及服务端返回的信息，同时保存登录时用户信息在xylftpauto.conf文件中，供自动登录使用。

2.2 运行环境

服务端支持i368，x86_64，客户端适用于所有可使用JVM的机器上。

2.3 基本设计概念和处理流程

服务端：
目的是设计一个简洁，高效的FTP服务器，并不涉及到较为复杂的安全策略(有关FTP的明文传输)，以较快的速度完成整体框架的设计，然后对具体模块进行改进，优化。
服务端程序配套的带有一个xylftptool的工具，可以用它来生成配置文件(当配置文件被改乱或者丢失的时候使用)，以及检查配置文件的错误，同时可以生成用户数据，采用md5加密存储。服务端启动的时候先读取xylftp.conf文件，将文件中的参数传递给主程序，然后通过参数解析函数完成参数的处理，把相应的值赋给全局变量以及函数。主程序调用ftp_linsten()函数进行监听,如果相应端口(未必是21,可根据xylftp.conf文件更改)有连接请求，则调用ftp_server()处理，此时应该考虑服务端使用的是passive还是port模式，分别采取不同的处理方式，如果是passive模式，则应开启相应的data port等待客户端的数据连接，如果是port模式，则使用端口20数据传输的初始化。随后该函数使用fork()建立新的进程处理用户请求。主程序继续处于ftp_listen()状态，直到进程被杀死。

客户端;
设计一个简单，实用的FTP客户端，支持常用的FTP命令，使用java标准库开发，并且预留GUI接口。
客户端首先接收命令行的输入，使用命令解释程序来解析命令，如果本地可以完全的命令，直接调用相应的函数完成，如果需要传送到远程FTP主机，则传输相应的命令到远程FTP。同时客户端不断接收服务端的处理结果，并显示。

2.4 结构

服务端：

2.5 功能需求与程序的关系

服务端提供FTP服务，客户端连接服务器使用其提供的功能。

2.6 人工处理过程

无人工处理过程

2.7 尚未解决的问题

服务端运行模式。

[b]三 接口设计 [/b]

3.1 用户接口

服务端不向用户提供任何命令，用户可以通过修改配置文件xylftp.conf文件来实现对服务端启动方式的修改。

客户端提供命令如help，quit,bye等，详见需求规定(暂时未完成)

3.2 外部接口

服务端需要在运行有Linux系统主机的shell下启动，无交互模式。客户端需要JVM的支持。

3.3 内部接口

见2.4结构

[b]四 运行设计[/b]

4.1 运行模块组合

(vsftpd有两种启动模式：stand alone以及super daemon,不知道我们需要这样做吗?具体两种方式见附文一。
服务端支持被动模式吗?如果支持被动模式难度似乎会增加很多，见附文二)

4.2 运行控制

由4.1决定

4.3 运行时间

由4.1决定

[b]五 系统数据结构设计[/b]

5.1 逻辑结构设计要点

应该要用到排序算法可使用哈唏排序

5.2 物理结构设计要点

直接使用系统调用存储文件，不考虑存取的物理关系。

5.3 数据结构与程序的关系

没必要

[b]六 系统出错处理设计[/b]

6.1 出错信息

服务端：
error01-读取xylftp.conf文件错误，请确认xylftp.conf存在，并且有读取权限。
error02-xylftp.conf文件格式错误，请根据说明更改xylftp.conf文件内容。
error03-xylftp已经运行，结束xylftp进行，重新启动。
error04-其它FTP服务器(也可能是其它应用程序)占用21端口，结束相关占用21端口程序的进程。
error05-用户名不存在，使用其它用户名登录，或者联系FTP管理员。
error06-密码错误，尝试其它密码，或者联系FTP管理员。
error07-[大家添加一些]
客户端：
error01-无法连接远程主机，请确认远程主机是否活动，使用ping命令，请确认远程主机是否使用默认端口21
error02-无法上传文件出错，请确认使用的用户是否具有相应目录的写权限。
error03-无法下载文件出错，请确认使用的用户是否具有相应的读取权限，以及本地目录是否有写入权限。
error04-下载过程中出错，请确认网络处于连接状态，并重新下载。
error05-远程主机关闭，请与远程FTP管理员联系。
error06-[大家添加一些]

6.2 补救措施

下载过程中出错(包括文件传输中断，以及文件校验不符)，则重新下载，重试次数3次。

6.3 系统维护设计

服务端运行时产生详细的运行记录供维护使用，客户端使用-d参数显示详细的服务端返回信息。

附文一：

vsftpd 啟動的模式
vsftpd 可以擁有兩種啟動的方式，分別是一直在監聽的 stand alone ，一種則是透過 xinetd 這個 super daemon 來管理的方式，兩種方式所使用的啟動程序不太相同，而我們的 CentOS 則預設是以 stand alone 來啟動的。 那什麼時候應該選擇 stand alone 或者是 super daemon 呢？如果你的 ftp 伺服器是提供給整個網際網路來進行大量下載的任務，例如各大專院校的 FTP 伺服器，那建議你使用 stand alone 的方式， 服務的速度上會比較好。如果僅是提供給內部人員使用的 FTP 伺服器，那使用 super daemon 來管理即可啊。

附文二：
Tinyftp is a small ftp server. It implements a set of all
the neccessary commands for performing the main actions,
suppported by the protocol. The server is based on rfc959.
This server does not support "passive" mode, because it needs
a simultaneous communication on a custom free port for
additional data transfers. For this we will need an IPC, which
hardens the implementation a lot.
The only valid user, that can log in is "anonymous", because of
the different authentication mechanism on different platforms.
All server options are set from the command line parameters.