Прегледани библиотеки за клиенти на Java FTP

Нека си представим ситуация, в която искаме да напишем чисто Java приложение, което трябва да изтегли файлове от отдалечен компютър, работещ с FTP сървър. Също така искаме да филтрираме изтеглянията въз основа на информация за отдалечен файл, като име, дата или размер.

Въпреки че е възможно и може би забавно да се напише обработващ протокол за FTP от нулата, това също е трудно, дълго и потенциално рисковано. Тъй като предпочитаме да не отделяме време, усилия или пари сами да пишем манипулатор, предпочитаме вместо това да използваме отново съществуващ софтуерен компонент. И много библиотеки са достъпни в глобалната мрежа. С FTP клиентска библиотека изтеглянето на файл може да бъде написано на Java толкова просто, колкото:

FTPClient ftpClient = нов FTPClient (); ftpClient.connect ("ftp.foo.com", "user01", "pass1234"); ftpClient.download ("C: \\ Temp \\", "README.txt"); // В крайна сметка други операции тук ... ftpClient.disconnect ();

Търсенето на качествена Java FTP клиентска библиотека, която отговаря на нашите нужди, не е толкова просто, колкото изглежда; може да бъде доста болезнено. Отнема известно време, за да се намери Java FTP клиентска библиотека. След това, след като намерим всички съществуващи библиотеки, коя да изберем? Всяка библиотека отговаря на различни нужди. Библиотеките са с неравно качество и дизайнът им се различава коренно. Всяка предлага различен набор от функции и използва различни видове жаргон, за да ги опише.

По този начин оценяването и сравняването на клиентските библиотеки на FTP може да се окаже трудно и объркващо. Повторното използване на съществуващи компоненти е похвален процес, но в този случай стартирането може да бъде обезсърчително. И това е срамно: след като изберете добра FTP библиотека, останалото е рутина.

Тази статия има за цел да направи този процес на подбор кратък, лесен и полезен. Първо изброявам всички налични FTP клиентски библиотеки. След това определям и описвам списък с подходящи критерии, към които библиотеките трябва да се обърнат по някакъв начин. И накрая, представям обзорна матрица, която дава бърз поглед върху това как библиотеките се подреждат една срещу друга. Цялата тази информация предоставя всичко, от което се нуждаем, за да вземем бързо, надеждно и дълготрайно решение.

FTP поддръжка в JDK

Референтната спецификация за FTP е Заявка за коментари: 959 (RFC959). Sun Microsystems осигурява внедряване на RFC959 в JDK, но е вътрешно, без документи и не е предоставен източник. Докато RFC959 се крие в сянка, той всъщност е задната част на публичен интерфейс, изпълняващ RFC1738, спецификацията на URL, както е показано на фигура 1.

В JDK се предлага стандартно изпълнение на RFC1738. Той върши разумна работа за основните операции по прехвърляне на FTP. Той е публичен и документиран и е предоставен изходен код. За да го използваме, пишем следното:

URL адрес на URL = нов URL ("ftp: // user01: [email protected]/README.txt; type = i"); URLConnection urlc = url.openConnection (); InputStream е = urlc.getInputStream (); // За изтегляне на OutputStream os = urlc.getOutputStream (); // Да качиш

Поддръжката на FTP клиенти в JDK стриктно следва стандартната препоръка, но има няколко недостатъка:

  • Той се различава основно от библиотеките на FTP клиенти на трети страни; те изпълняват RFC959, а не RFC1738.
  • RFC959 е внедрен в повечето инструменти за FTP-клиенти за настолни компютри. Много програмисти на Java използват тези инструменти за свързване към FTP сървъри. Що се отнася до вкуса, тези инструменти най-вероятно предпочитат подобни на RFC959 библиотеки.
  • На URLи URLConnectionкласове само отворените потоци за комуникация. Библиотечни оферти без право подкрепата The Sun за структуриране суровини FTP сървър отговорите на по-използваеми Java обектите като String, File, RemoteFile, или Calendar. Така че трябва да напишем повече код, само за да запишем данни във файл или да използваме списък с директории.
  • Както е обяснено в раздел 3.2.5 на RFC1738, „Оптимизация“, FTP URL адресите изискват (контролната) връзка да се затваря след всяка операция. Това е разточително и не е ефективно за прехвърляне на много малки файлове. Освен това, изключително ограничителните FTP сървъри могат да разглеждат такава комуникация като злонамерена мрежова атака или злоупотреба и да отказват допълнителна услуга.
  • И накрая, липсват няколко полезни функции.

Поради всички или някоя от тези причини използването на библиотека на трети страни е за предпочитане. Следващият раздел изброява наличните алтернативи на трети страни.

Библиотечно сравнение

Списъкът по-долу очертава библиотеките, които сравнявам в тази статия. Всички те следват референтната FTP спецификация. По-долу споменавам името на доставчика и името на библиотеката (с курсив). Ресурсите включват връзки към уебсайта на всеки продукт. За да използвам библиотеката с ускорен старт, споменавам и основния FTP клиентски клас.

  1. JScape, iNet Factory :com.jscape.inet.ftp.Ftp
  2. / n софтуер, IP * Работи :ipworks.Ftp
  3. Enterprise Distributed Technologies, Java FTP Client Library :com.enterprisedt.net.ftp.FTPClient
  4. IBM alphaWorks, FTP Bean Suite :com.ibm.network.ftp.protocol.FTPProtocol
  5. SourceForge, JFtp :net.sf.jftp.net.FtpConnection
  6. Проектът Джакарта, Джакарта Commons / Net :org.apache.commons.net.ftp.FTPClient
  7. JavaShop JNetBeans :jshop.jnet.FTPClient
  8. Слънце, JDK :sun.net.ftp.FtpClient
  9. Florent Cueto, JavaFTP API :com.cqs.ftp.FTP
  10. Беа Петровикова , jFTP :cz.dhl.ftp.Ftp
  11. Проектът Globus, Java CoG Kit :org.globus.io.ftp.FTPClient

Бележки:

  • По време на това писане IBM оценява целесъобразността на предлагането на своя alphaWorks FTP Bean Suite на своя уебсайт. Засега изтеглянето е затворено за всички потребители.
  • Джакарта Commons / Net е заместващ заместител на Savarese NetComponents, който вече не е разработен.
  • JavaShop JNetBeans изглежда е изоставен. По време на това писане сайтът е офлайн повече от месец и никога не съм получавал отговори на молбите си за поддръжка.

Критерии

Досега въведох контекста и изброих наличните библиотеки. Сега изброявам съответните критерии, по които ще се оценява всяка библиотека. Изброявам възможни стойности за всеки критерий, заедно с абревиатурата ( получер ), използвана в матрицата за окончателно сравнение.

Поддръжка на продукти

Библиотеките предоставят поддръжка на потребителите чрез продуктова документация, компилиран Javadocs, примерен код и примерно приложение, което може да включва коментари и обяснения. Допълнителна поддръжка може да се предложи на потребителите чрез форуми, пощенски списъци, имейл адрес за контакт или онлайн система за проследяване на грешки. / n софтуерът предлага обширна поддръжка срещу допълнително заплащане.

Мотивацията на администратора за поддръжка е важен фактор за бърза поддръжка. Администраторите за поддръжка могат да бъдат:

  • Доброволно лице ( I )
  • Доброволна група ( G )
  • Професионален субект, платен за предоставяне на подкрепа ( P )

Разрешително

За търговските проекти лицензът за продукт е важен въпрос, който трябва да се разгледа от самото начало. Някои библиотеки могат свободно да се преразпределят в търговски продукти, а други не могат. Например GPL (GNU General Public License) е силен, ограничаващ лиценз, докато софтуерният лиценз Apache изисква само споменаване в преразпределени продукти.

Търговските лицензи ограничават броя програмиращи работни станции за програмиране с библиотеката, но разпространението на самата библиотека не е ограничено.

За нетърговските проекти лицензирането е по-скоро въпрос на философия; безплатен продукт е забележим.

Лицензите могат да бъдат:

  • Търговски ( C )
  • GPL ( G )
  • Free (F); however, check a free license for limitations

Some library providers provide alternate, less-restrictive licenses on demand.

Source code provided

A closed-sourced, black-box software library can be irritating. Having source code can be more comfortable for the following reasons:

  • When debugging application code execution, stepping into the library code source can help you understand library behavior
  • The source code has useful comments
  • Source code can be quickly tweaked to match special needs
  • Exemplary source code can be inspiring

Age

Libraries have been tested, debugged, and supported since their first public release. As version numbering varies among libraries, I base this criterion on the year of the earliest public release.

Directory listing support

Retrieving remote file information (name, size, date) from the server is important in most applications. The FTP protocol offers the NLST command to retrieve the file names only; the NLST command is explicitly designed to be exploited by programs. The LIST command offers more file information; as RFC959 notes, "Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user." No other standard method retrieves file information; therefore, client libraries try to exploit the LIST response. But this is not an easy task: since no authoritative recommendation is available for the LIST response format, FTP servers have adopted various formats:

  • Unix style: drwxr-xr-x 1 user01 ftp 512 Jan 29 23:32 prog
  • Alternate Unix style: drwxr-xr-x 1 user01 ftp 512 Jan 29 1997 prog
  • Alternate Unix style: drwxr-xr-x 1 1 1 512 Jan 29 23:32 prog
  • A symbolic link in Unix style: lrwxr-xr-x 1 user01 ftp 512 Jan 29 23:32 prog -> prog2000
  • Weird Unix style (no space between user and group): drwxr-xr-x 1 usernameftp 512 Jan 29 23:32 prog
  • MS-DOS style: 01-29-97 11:32PM prog
  • Macintosh style: drwxr-xr-x folder 0 Jan 29 23:32 prog
  • OS/2 style: 0 DIR 01-29-97 23:32 PROG

Unix style, then MS-DOS style, are the most widespread formats.

Java FTP client libraries try to understand and auto-detect as many formats as possible. In addition, they offer various alternatives for handling unexpected format answers:

  • An additional method returning a raw FTP response as one string (S)
  • An additional method returning a collection of raw strings, one string per line/file (C)
  • A framework supporting pluggable parsers (P)

Most libraries parse LIST responses and structure raw file information into Java objects. For example, with JScape iNet Factory, the following code retrieves and exploits file information received in a directory listing:

java.util.Enumeration files = ftpClient.getDirListing(); while (files.hasMoreElements()) { FtpFile ftpFile = (FtpFile) files.nextElement(); System.out.println(ftpFile.getFilename()); System.out.println(ftpFile.getFilesize()); // etc. other helpful methods are detailed in Javadoc } 

Section "Solutions for Remaining Problems" further considers directory listings.

Timestamp retrieval

In many cases, we are interested in a remote file's latest modification timestamp. Unfortunately, no RFC introduces a standard FTP command to retrieve this information. Two de facto methods exist:

  1. Retrieve this information from the LIST response by parsing the server answer. Unfortunately, as you learned in the previous section, the LIST response varies among FTP servers, and the timestamp information is sometimes incomplete. In the Unix format, imprecision occurs when the remote file is more than one year old: only the date and year, but not hours or minutes are given.
  2. Use the nonstandard MDTM command, which specifically retrieves a remote file's last modification timestamp. Unfortunately, not all FTP servers implement this command.

An intricate alternative to MDTM command support is to send a raw MDTM command and parse the response. Most libraries provide a method for sending a raw FTP command, something like:

String timeStampString = ftpClient.command("MDTM README.txt"); 

Another possible concern is that FTP servers return time information in GMT (Greenwich Mean Time). If the server time zone is known apart from FTP communication, the java.util.TimeZone.getOffset() method can help adjust a date between time zones. See JDK documentation for further information about this method.

Section "Solutions for Remaining Problems" further considers file timestamp retrieval.

Firewalls

Typically, a firewall is placed between a private enterprise network and a public network such as the Internet. Access is managed from the private network to the public network, but access is denied from the public network to the private network.

Socks is a publicly available protocol developed for use as a firewall gateway for the Internet. The JDK supports Socks 4 and Socks 5 proxies, which can be controlled by some of the libraries. As an alternative, the JVM command line can set the Socks proxy parameters: java -DsocksProxyPort=1080 -DsocksProxyHost=socks.foo.com -Djava.net.socks.username=user01 -Djava.net.socks.password=pass1234 ...

Another common alternative to Socks proxy support is to "socksify" the underlying TCP/IP layer on the client machine. A product like Hummingbird can do that job.

The JDK also supports HTTP tunnels. These widespread proxies do not allow FTP uploads. /n software's IP*Works allows you to set HTTP tunnel parameters.

Повечето библиотеки поддържат активни и пасивни връзки: пасивната връзка е полезна, когато клиентът е зад защитна стена, която инхибира входящите връзки към по-високи портове. RFC1579 разглежда по-подробно тази удобна за защитна стена функционалност. Документацията на някои продукти се отнася до активни и пасивни връзки съответно като PORTи PASVкоманди.

Паралелен трансфер

В настолно приложение, когато трансферът започне в основната единична нишка, всичко замръзва. Някои библиотеки автоматично обслужват цикъла на събитията за паралелни прехвърляния в отделни нишки, така че не е нужно да създаваме и управляваме собствени нишки.

Поддръжка на спецификация JavaBean

Някои библиотеки изпълняват спецификацията JavaBean. Съответствието с JavaBean позволява визуално програмиране, което се предлага в основните Java IDE.