站内搜索: 请输入搜索关键词

当前页面: 开发资料首页Java 专题Java FTP libraries 比较

Java FTP libraries 比较

摘要: Java FTP libraries 比较
内容: 正如我以前在JavaWorld上发表的文章Java FTP Client Libraries Reviewed中讨论的一样(2003年4月),JDK对FTP的支持并不完全的符合FTP规范。(FTP规范了959条项目)比如JDK不允许在服务器端创建文件夹或者FTP连接对同一个文件打开两个相同的连接。所以当和RFC959比较时,证明JDK并不是完全令人满意的。而且,当使用JDK所支持的FTP时,FTP服务器端返回的是无格式的字符串,而不是方便的java对象。为了完全的获得RFC959的支持和提供方便的方法,java开发者们必须求助于市面上的第三方库
许多的JAVA FTP库都可以在网上找到,他们有:

--JScape's Secure FTP Factory
--Enterprise Distributed Technologies' FTPj
--JFtp
--Jakarta Commons/Net
--Sun JDK
--Florent Cueto's JavaFTP API
--Bea Petrovicova's jvFTP
--The Globus Alliance's Java CoG Kit
--Glub Tech's Secure FTP Bean
--Calvin Tai's FtpBean

这个列表非常的长,所以对这些库进行比较非常的不直观。甚至这些库都实现各自不同的特性,不同的价格,而且水平的质量和使用条款也不同。所以选择一个和具体需求细节有关的库文件非常的麻烦。为了帮助决策者选择一个适合他们需求的库,这篇文章对这些库进行比较和评价。

版权声明:任何获得Matrix授权的网站,转载时请务必保留以下作者信息和链接
作者:Jean-Pierre Norguet ;tain198127(作者的blog:http://blog.matrix.org.cn/page/tain198127)
原文:http://www.javaworld.com/javaworld/jw-03-2006/jw-0306-ftp.html
Matrix:http://www.matrix.org.cn/resource/article/44/44480_Java+FTP+libraries.html
关键字:Java;FTP;libraries

这些比较采用了一系列的标准,包括所支持的特性,提供者的商业方面,还有文件传输性能。我采用了一些Java FTP Client Libraries Reviewed中的标准。请查阅该文章进行回顾。为了进行评估而建立的新标准是“安全支持标准”还有“文件传输性能标准”。“安全支持标准”指明这些库是否实现了FTP的延伸安全性。“文件传输性能标准”是比较这些库的传输速度
关于FTP的“安全支持标准”在Internet Engineering Task Force's reference document RFC2228中有定义。根据建议FTP“安全支持标准”主要是两种类型。隐式的和显式的。隐式的FTP“安全支持标准”实际就是在建立在安全传输层的FTP协议,采用直接的SSL连接,默认通过990端口。显式FTP“安全支持标准”,是建立在SSL上的FTP,但是用隐降牧犹娲酥苯拥腟SL连接,它是先采用普通的FTP协议连接到服务器,然后再用AUTHSSL 或者AUTH TLS命令转换到SSL安全连接来转换到SSL安全模式的。显式SSL和隐式SSL都是典型的提交到FTPS的。FTP“安全支持标准”还可以实现SSH子协议的方式实现(SSH是安全外壳)。这种实现是提交到SFTP的。尽管协议的名字和功能类似,但是他和前面提到的模式是完全不一样的。Java FTP Client Libraries Reviewed中比较明确指出了每个库文件支持的FTP标准到底是SFTP还是FTPS。

库的“文件传输性能标准”比较表是基于两种传输标准的。第一种标准描述的是传输一个大型文件的速度并标明数据通过网络传输到对方的时间。第二种标准用来测量传输许多小型文件的速度,并指明该库用于连接服务端的时间。在根据具体的应用程序选择最合适的文件时,这两种标准会起到帮助。例如:在为视频传输的应用中应以该库的传输大数据的得分为标准,而为那些用户和FTP服务器进行许多交互的应用上,就该以其传输许多小数据的得分为标准。

试验

试验常用的测量方法列在后面:在FTP服务器端创建一个大文件和许多小文件,这些文件(大文件和小文件)是用来分别测量服务器传输大文件和小文件的速度的。这些数据的数量和大小被设计成相同的数据量。而且是采用两台相似的机器通过TCP/IP网络协议进行测试的。为了保证测试数据的正确性,在测试过程中任何其他的网络传输都被排斥在外了。而且,为了保证所测数据均匀分布,我做了10次测量,再取其平均值。

试验的设置如下:传输数据量是10MB。所以,大文件大小就是10MB。小文件大小是1K,数量是10000。网络测量单位是10 Mbits/s Ethernet network。客户端是IBM的VisualAge for Java4.0,系统是windows xp. 服务器端是RedHat Linux Fedora Core 2.服务器软件是vsFTDd for Linux。结果,其测试代码Java FTP Client Libraries Reviewed内有详细描述,也可以到Resources进行下载。

为了重现试验,你可以根据以下操作进行测试:从Resources下载测试代码,Benchmark.java。测试代码实现了Benchmark 类,这个类中包含了许多的内部类。每个内部类都为各个库实现了文件传输操作。可以通过编译运行该程序来测试放在classpath下的库。可执行程序只接受一个参数:工作空间地址的路径。这个地址必须包含一个main.config文件,这个文件中包含了配置参数。一个简单的配置文件main.config可以从Resources下载。执行之后,会产生出一个测量结果文件,其中的测量结果用逗号分隔。该文件可以在工作空间中找到。这个文件可以用电子表格软件来打开,比如微软的Excel。

结果

根据试验协议和设定,我得到了分别针对大文件和小文件传输的两组测量数据。每组测量都显式为独立的图表。所有的库都在左边,他们传输速度以单杠形式显式在右边。为了提供绝对比例的测量,传输速度是用传输时间的倒数乘以最短的传输时间。(就是一个百分比,最短传输时间/测量的传输时间,这样最快的就是100,其他的依此类推,有点类似于高考中的标准分的概念)。这样得到100分的就是最快的库,我也显示了WIN XP FTP命令行的FTP测量速度。

在大文件传输测试图中(图1),你可以发现许多的库都拥有比较高的速度,他们之间的差距比较小。所以,大部分的库比较适合传输大型数据文件。这些库的记录工作没有任何的优化。许多库的传输速度也许得益于优化的操作。最典型的优化方法是:设置通讯连接input/output 数组的长度。因此,最佳优化后的库可以在相同的速度下传输大块的数据。(也就是说,通过优化,设置input,output的数组长度——也就是缓冲区,那么即使是相同的速度下,可以传输大数据,即这样优化后对传输大数据有利)


Figure 1. Large-file transfer speed

小文件传输测试图(图2)显示EnterpriseDT's edtFTPj, Calvin Tai's FtpBean, and Glub Tech's Secure FTP Bean的性能比其他库更优越,甚至比WIN XP FTP命令行的速度还高。在SUN 的JDK中有一个明显的BUG,就是在下载了200个文件之后,JDK拒绝传输,提示内存错误。在图表中,我只对前200个传输进行了统计。而分数最低的原因是因为每个download操作都需要新建一个新的connection来进行打开和关闭操作。这种引入连接方式是针对单个文件传输的。总之,JDK架设的FTP只适合下载文件数量较少的情况。


Figure 2. Small-file transfer speed

回顾一下每个库的特性,点击here可以得到比较的列表。库的名字显示在最上面,标准出现在左边,每个单元的的缩写在每个表格中的关键字中有解释。

总结
这篇文章是建立于我以前在JavaWorld发表的文章"Java FTP Client Libraries Reviewed"上的,并且是用于研究JAVA平台上对FTP的支持。在性能方面,对大文件的传输结果比较相似。对于小文件传输测试,EnterpriseDT's edtFTPj, Calvin Tai's FtpBean,和Glub Tech's Secure FTP Bean是最好的选择,然而SUN的JDK需要解决下载数不能超过200个文件的BUG。关于其他方面的测试,可以查阅测试比较列表。

由于很多的第三方库都支持FTP RFC959,开发者可以根据自己的需求选择最有效率的库了。然而,使用第三方库会增加程序的复杂度。例如一个APPLET被配置在客户端,可能需要下载到服务器端。如果JDK完全的支持FTP的话,那么就不会出现这种隐藏的复杂度问题了。

为了使JDK完全的支持FTP,一个RFE已经被提交到了Sun Developer Network Bug Database了,在一个不断成长的社区30个月持续不断的支持下,为该REF投票的人数已经从最初的8个人增长到88个人,使得这个RFE成了最高的25个RFE之一。然而,直到我写这篇文章的时候,SUN的工程师还没有解决该RFE,也没有公布该RFE的解决时刻表。

同时,Java FTP API标准化项目组织也支持FTP RFE,这个项目组织的目标是将支持该RFE的社区的成员集合起来,从而提供在JAVA平台上可用资源。这个项目也努力的召集一个专家组向JCP提交相关的JSR。这个JSR将会以JAVA平台标准实现RFC959协议,从而实现对FTP的完全支持。然而,这个专家组还没有成型,而且提交该JSR成为标准的时间还没有确定。总之,让JAVA平台支持FTP的特性是有好处的。

资源
Matrix:http://www.matrix.org.cn
Javaworld:http://www.javaworld.com

Java, java, J2SE, j2se, J2EE, j2ee, J2ME, j2me, ejb, ejb3, JBOSS, jboss, spring, hibernate, jdo, struts, webwork, ajax, AJAX, mysql, MySQL, Oracle, Weblogic, Websphere, scjp, scjd 正如我以前在JavaWorld上发表的文章Java FTP Client Libraries Reviewed中讨论的一样(2003年4月),JDK对FTP的支持并不完全的符合FTP规范。(FTP规范了959条项目)比如JDK不允许在服务器端创建文件夹或者FTP连接对同一个文件打开两个相同的连接。所以当和RFC959比较时,证明JDK并不是完全令人满意的。而且,当使用JDK所支持的
↑返回目录
前一篇: Java线程总结
后一篇: J2SE 5.0中的泛型