有趣的FTP客户端,编写FTP服务器有感

safedead

自己写了一个多线程FTP服务器
测试中遇到无数烂客户端，从而不断改进
同时逐渐明白为啥win32的FTP客户端要收费了

1、win2k的IE6
这个IE6很有趣，它同时发起两个连接到FTP服务器
一个用于LIST/MKD/DELE，另一个用于RETR/STOR
问题是这两个连接没有正确共享帐号，如果第一次登录出错，改正帐号后
只有一个连接被更正，然后浏览器就死循环，重开IE才能恢复正常
重开IE之前，俺的FTP登录日志会无限增长，正确和错误交替出现

2、winXP的IE6
这个IE6除了双连接以外，有另外一项功能，在上传目录时，每个目录要创建两次
vsFTP会耐心的返回550错误，我经过考虑，决定当目录已经创建时，返回成功而不是550
这下XP的IE6不用我去点鼠标了，但是上传完毕，IE窗口显示文件和目录都是双份
刷新页面后正常，显然，这个IE6在上传之后没有LIST，而是根据自己的操作记录显示

3、win2003上的IE7
这个一切正常

我用LINUX的gFTP从来没提要钱的事情，没有这样那样的有趣行为
但是win32的FTP客户端，稍微好用一点的都要钱

现在我理解vsFTP为啥在LIST之后连续返回150和226响应了，因为IE6没有接到226就不接收数据通道内容
可是传输文件千万不能把150和226一起发，那样的话FlashFXP会直接中断数据连接
所以传目录时，150和226一起发，传文件时，数据通道关闭再发226

nully

IE6的FTP实现确实垃圾...

safedead

原帖由 pinyin 于 2007-11-2 15:22 发表

为何不换个方法，预先知道每一块在文件中的位置，直接写文件，互不干扰

位置是预先知道的，就是REST命令的参数，但是应用不能看见正在写的文件

safedead

原帖由 flw 于 2007-11-2 15:08 发表

应该没有吧。
它好像是一个连接就是一个进程/线程。
然后多个连接并发写同一个文件，用 O_RDWR 打开，seek 到 REST 指定的偏移量，如果长度不够就会扩展空洞。

我现在有个疑问，关于fseek(fp, offset, SEEK_SET)
书上说，如果offset超过了文件结尾
那么将产生文件空洞
这个文件空洞对文件系统有什么样的影响？
空洞被填补写入足够的数据以后，是否和正常文件完全一致？
gawk的作者写了一本LINUX编程的书提到了空洞的产生原因
但没说空洞文件会对文件系统产生不良影响
可以放心的使用带空洞的文件么？

pinyin

原帖由 safedead 于 2007-11-2 14:44 发表
多线程上传对我的程序来讲
最大的问题是异步合并
比如文件被平均拆开成5块传输
没准第5块会第一个传完，因为最后一块往往是最小的一块！
必须等待所有的段落传输完毕才能正确合并
这个合并过程不应该阻塞任 ...

为何不换个方法，预先知道每一块在文件中的位置，直接写文件，互不干扰

flw

原帖由 飞灰橙 于 2007-11-2 15:00 发表

請問他有對seek次數做優化嗎？

应该没有吧。
它好像是一个连接就是一个进程/线程。
然后多个连接并发写同一个文件，用 O_RDWR 打开，seek 到 REST 指定的偏移量，如果长度不够就会扩展空洞。

飞灰橙

原帖由 flw 于 2007-11-2 14:50 发表

我觉得 wu-ftpd 的做法很直观，很正确。
它是直接打开目标文件 seek 后写的。
只不过你刚才说了，你的应用要求必须要有临时文件。

請問他有對seek次數做優化嗎？

flw

原帖由 safedead 于 2007-11-2 14:44 发表
多线程上传对我的程序来讲
最大的问题是异步合并
比如文件被平均拆开成5块传输
没准第5块会第一个传完，因为最后一块往往是最小的一块！
必须等待所有的段落传输完毕才能正确合并
这个合并过程不应该阻塞任 ...

我觉得 wu-ftpd 的做法很直观，很正确。
它是直接打开目标文件 seek 后写的。
只不过你刚才说了，你的应用要求必须要有临时文件。

safedead

多线程上传对我的程序来讲
最大的问题是异步合并
比如文件被平均拆开成5块传输
没准第5块会第一个传完，因为最后一块往往是最小的一块！
必须等待所有的段落传输完毕才能正确合并
这个合并过程不应该阻塞任何一个相关的FTP会话线程

我应该去参考一下BT的做法，那个在大文件合并和异步问题的处理解决的非常好

flw

原帖由 safedead 于 2007-11-2 13:50 发表


多线程下载可以，上传不行，文件会乱掉

我的接收文件算法是这样实现的
在数据连接正确建立之后
首先生成带绝对路径的真正文件名
在一个所有用户都不可见的临时目录里，用线程id为临时文件名
接收数据 ...

的确是这样，多线程上传是比较难做，需要考虑的问题比较多。
况且也不太常用。
FTP 协议规范是支持的，服务器实现的时候通常都不能很好的支持 REST+STOR