Java FTP-klientbiblioteker gjennomgått

La oss forestille oss en situasjon der vi ønsker å skrive et rent Java-program som må laste ned filer fra en ekstern datamaskin som kjører en FTP-server. Vi ønsker også å filtrere nedlastinger på grunnlag av ekstern filinformasjon som navn, dato eller størrelse.

Selv om det er mulig, og kanskje morsomt, å skrive en protokollbehandler for FTP fra bunnen av, er det også vanskelig, langt og potensielt risikabelt. Siden vi helst ikke vil bruke tid, krefter eller penger på å skrive en handler alene, foretrekker vi i stedet å bruke en eksisterende programvarekomponent. Og mange biblioteker er tilgjengelige på Internett. Med et FTP-klientbibliotek kan nedlasting av en fil skrives på Java så enkelt som:

FTPClient ftpClient = ny FTPClient (); ftpClient.connect ("ftp.foo.com", "user01", "pass1234"); ftpClient.download ("C: \ Temp \", "README.txt"); // Til slutt andre operasjoner her ... ftpClient.disconnect ();

Å lete etter et Java FTP-klientbibliotek av høy kvalitet som samsvarer med våre behov er ikke så enkelt som det virker; det kan være ganske vondt. Det tar litt tid å finne et Java FTP-klientbibliotek. Så, etter at vi har funnet alle eksisterende biblioteker, hvilken velger vi? Hvert bibliotek imøtekommer forskjellige behov. Bibliotekene har ulik kvalitet, og designene deres skiller seg fundamentalt. Hver har forskjellige funksjoner og bruker forskjellige typer sjargong for å beskrive dem.

Det kan derfor være vanskelig og forvirrende å evaluere og sammenligne FTP-klientbiblioteker. Gjenbruk av eksisterende komponenter er en prisverdig prosess, men i dette tilfellet kan det være nedslående å starte. Og dette er synd: etter å ha valgt et godt FTP-bibliotek, er resten rutinemessig.

Denne artikkelen tar sikte på å gjøre den valgte prosessen kort, enkel og verdifull. Jeg lister først opp alle tilgjengelige FTP-klientbiblioteker. Deretter definerer jeg og beskriver en liste over relevante kriterier som bibliotekene skal adressere på en eller annen måte. Til slutt presenterer jeg en oversiktsmatrise som gir en rask oversikt over hvordan bibliotekene stabler opp mot hverandre. All denne informasjonen gir alt vi trenger for å ta en rask, pålitelig og langvarig beslutning.

FTP-støtte i JDK

Referansespesifikasjonen for FTP er Request for Comments: 959 (RFC959). Sun Microsystems gir en RFC959-implementering i JDK, men den er intern, papirløs og ingen kilde er gitt. Mens RFC959 ligger i skyggen, er det faktisk bakenden av et offentlig grensesnitt som implementerer RFC1738, URL-spesifikasjonen, som illustrert i figur 1.

En implementering av RFC1738 tilbys som standard i JDK. Det gjør en rimelig jobb for grunnleggende FTP-overføringsoperasjoner. Den er offentlig og dokumentert, og kildekoden er gitt. For å bruke den skriver vi følgende:

URL url = ny URL ("ftp: // user01: [email protected]/README.txt; type = i"); URLConnection urlc = url.openConnection (); InputStream er = urlc.getInputStream (); // For å laste ned OutputStream os = urlc.getOutputStream (); // Å laste opp

FTP-klientstøtte i JDK følger strengt standardanbefalingen, men den har flere ulemper:

Det skiller seg fundamentalt fra tredjeparts FTP-klientbiblioteker; disse implementerer RFC959 i stedet for RFC1738.
RFC959 er implementert i de fleste desktop FTP-klientverktøy. Mange Java-programmerere bruker disse verktøyene for å koble til FTP-servere. Som et spørsmål om smak, foretrekker disse verktøyene mest sannsynlig RFC959-lignende biblioteker.
De URL og URLtilkobling klasser åpner bare strømmer for kommunikasjon. Sun-biblioteket tilbyr ingen direkte støtte for å strukturere de rå FTP-serverresponsene i mer brukbare Java-objekter som String, Fil, RemoteFile, eller Kalender. Så vi må skrive mer kode bare for å skrive data i en fil eller for å utnytte en katalogoppføring.
Som forklart i avsnitt 3.2.5 i RFC1738, "Optimalisering", krever FTP-URL-er at (kontroll) -forbindelsen lukkes etter hver operasjon. Dette er bortkastet og ikke effektivt for overføring av mange små filer. Videre kan ekstremt restriktive FTP-servere vurdere en slik kommunikasjonskostnad som et ondt nettverksangrep eller misbruk og nekte ytterligere service.
Til slutt mangler den flere nyttige funksjoner.

Av alle eller noen av disse grunnene er det å foretrekke å bruke et tredjepartsbibliotek. Den følgende delen viser tilgjengelige tredjepartsalternativer.

Bibliotek sammenligning

Listen nedenfor viser bibliotekene jeg sammenligner gjennom hele denne artikkelen. De følger alle FTP-spesifikasjonene. Nedenfor nevner jeg leverandørnavnet og biblioteksnavnet (i kursiv). Ressurser inkluderer lenker til hvert produkts nettsted. For å starte biblioteksbruk, nevner jeg også den viktigste FTP-klientklassen.

JScape, iNet Factory: com.jscape.inet.ftp.Ftp
/ n programvare, IP * fungerer: ipworks.Ftp
Enterprise Distributed Technologies, Java FTP-klientbibliotek: com.enterprisedt.net.ftp.FTPClient
IBM alphaWorks, FTP Bean Suite: com.ibm.network.ftp.protocol.FTPProtocol
SourceForge, JFtp: net.sf.jftp.net.FtpConnection
Jakarta-prosjektet, Jakarta Commons / Net: org.apache.commons.net.ftp.FTPClient
JavaShop JNetBeans: jshop.jnet.FTPClient
Sol, JDK: sun.net.ftp.FtpClient
Florent Cueto, JavaFTP API: com.cqs.ftp.FTP
Bea Petrovicova, jFTP: cz.dhl.ftp.Ftp
Globus-prosjektet, Java CoG-sett: org.globus.io.ftp.FTPClient

Merknader:

I skrivende stund vurderer IBM egnetheten av å tilby sin alphaWorks FTP Bean Suite på sitt nettsted. Foreløpig er nedlasting stengt for alle brukere.
Jakarta Commons / Net er en drop-in erstatning for Savarese NetComponents, som ikke lenger er utviklet.
JavaShop JNetBeans ser ut til å ha blitt forlatt. I skrivende stund har nettstedet vært frakoblet i mer enn en måned, og jeg har aldri fått svar på supportforespørslene mine.

Kriterier

Så langt har jeg introdusert konteksten og listet opp tilgjengelige biblioteker. Nå lister jeg opp de relevante kriteriene som hvert bibliotek vil bli vurdert etter. Jeg oppregner mulige verdier for hvert kriterium, sammen med forkortelsen (i dristig) brukt i den endelige sammenligningsmatrisen.

Produktstøtte

Bibliotekene gir støtte til brukere gjennom produktdokumentasjon, kompilert Javadocs, eksempelkode og et eksempel på et program som kan inneholde kommentarer og forklaringer. Ytterligere støtte kan tilbys til brukere gjennom fora, adresselister, en kontakt-e-postadresse eller et online feilsporingssystem. / n programvare tilbyr omfattende støtte mot en ekstra avgift.

En supportadministrators motivasjon er en viktig faktor for rask støtte. Støtteadministratorer kan være:

En frivillig person (Jeg)
En frivillig gruppe (G)
En profesjonell enhet betalt for å gi støtte (P)

Tillatelse

For kommersielle prosjekter er en produktlisens en viktig sak å vurdere fra begynnelsen. Noen biblioteker kan distribueres fritt i kommersielle produkter, og andre kan ikke. For eksempel er GPL (GNU General Public License) en sterk, begrensende lisens, mens Apache Software-lisensen bare krever en omtale i omfordelte produkter.

Kommersielle lisenser begrenser antall utviklingsarbeidsstasjoner som programmeres med biblioteket, men distribusjon av selve biblioteket er ikke begrenset.

For ikke-kommersielle prosjekter er lisens mer et spørsmål om filosofi; et gratis produkt er merkbart.

Lisenser kan være:

Kommersiell (C)
GPL (G)
Gratis (F); sjekk imidlertid en gratis lisens for begrensninger

Noen bibliotekleverandører tilbyr alternative, mindre restriktive lisenser på forespørsel.

Kildekode oppgitt

Et programvare-bibliotek med svart kilde-programvare kan være irriterende. Å ha kildekode kan være mer behagelig av følgende årsaker:

Når du feilsøker kjøring av applikasjonskoder, kan det å hjelpe deg med å forstå bibliotekets atferd å gå inn i bibliotekodekilden
Kildekoden har nyttige kommentarer
Kildekoden kan raskt justeres for å matche spesielle behov
Eksempler på kildekode kan være inspirerende

Alder

Biblioteker har blitt testet, feilsøkt og støttet siden den første offentlige utgivelsen. Siden versjonsnummerering varierer mellom biblioteker, baserer jeg dette kriteriet på året for den første offentlige utgivelsen.

Støtte for katalogoppføring

Å hente ekstern filinformasjon (navn, størrelse, dato) fra serveren er viktig i de fleste applikasjoner. FTP-protokollen tilbyr NLST kommando for å bare hente filnavnene; de NLST kommandoen er eksplisitt designet for å bli utnyttet av programmer. De LISTE kommando tilbyr mer filinformasjon; som RFC959 bemerker, "Siden informasjonen i en fil kan variere mye fra system til system, kan denne informasjonen være vanskelig å bruke automatisk i et program, men kan være ganske nyttig for en menneskelig bruker." Ingen andre standardmetoder henter filinformasjon; Derfor prøver klientbiblioteker å utnytte LISTE respons. Men dette er ikke en lett oppgave: siden ingen autoritativ anbefaling er tilgjengelig for LISTE responsformat, har FTP-servere tatt i bruk forskjellige formater:

Unix stil: drwxr-xr-x 1 bruker01 ftp 512 29. jan 23:32 prog
Alternativ Unix-stil: drwxr-xr-x 1 bruker01 ftp 512 29. jan 1997 prog
Alternativ Unix-stil: drwxr-xr-x 1 1 1 512 29. jan 23:32 prog
En symbolsk lenke i Unix-stil: lrwxr-xr-x 1 bruker01 ftp 512 29. jan 23:32 prog -> prog2000
Merkelig Unix-stil (ikke mellomrom mellom bruker og gruppe): drwxr-xr-x 1 usernameftp 512 29. jan 23:32 prog
MS-DOS stil: 01-29-97 23:32 prog
Macintosh-stil: drwxr-xr-x-mappe 0 29. jan 23:32 prog
OS / 2-stil: 0 DIR 01-29-97 23:32 PROG

Unix-stil, deretter MS-DOS-stil, er de mest utbredte formatene.

Java FTP-klientbiblioteker prøver å forstå og automatisk oppdage så mange formater som mulig. I tillegg tilbyr de ulike alternativer for håndtering av uventede formatsvar:

En ekstra metode som returnerer et rå FTP-svar som en streng (S)
En ekstra metode som returnerer en samling råstrenger, en streng per linje / fil (C)
Et rammeverk som støtter pluggbare parsers (P)

De fleste biblioteker analyserer LISTE svar og strukturere rå filinformasjon i Java-objekter. For eksempel, med JScape iNet Factory, henter og utnytter følgende kode filinformasjon mottatt i en katalogoppføring:

java.util.Enumeration files = ftpClient.getDirListing (); mens (files.hasMoreElements ()) {FtpFile ftpFile = (FtpFile) files.nextElement (); System.out.println (ftpFile.getFilename ()); System.out.println (ftpFile.getFilesize ()); // etc. andre nyttige metoder er beskrevet i Javadoc}

Avsnitt "Løsninger for gjenværende problemer" vurderer katalogoppføringer nærmere.

Henting av tidsstempel

I mange tilfeller er vi interessert i en ekstern fils siste tidsstempel for modifikasjon. Dessverre introduserer ingen RFC en standard FTP-kommando for å hente denne informasjonen. To de facto-metoder eksisterer:

Hent denne informasjonen fra LISTE svar ved å analysere serversvaret. Dessverre, som du lærte i forrige avsnitt, LISTE svaret varierer mellom FTP-servere, og tidsstempelinformasjonen er noen ganger ufullstendig. I Unix-formatet oppstår upresisjon når den eksterne filen er mer enn ett år gammel: bare dato og år, men ikke timer eller minutter er gitt.
Bruk ikke-standard MDTM kommando, som spesifikt henter en ekstern fils siste tidsstempel for modifikasjon. Dessverre implementerer ikke alle FTP-servere denne kommandoen.

Et intrikat alternativ til MDTM kommandostøtte er å sende en rå MDTM kommandere og analysere responsen. De fleste biblioteker tilbyr en metode for å sende en rå FTP-kommando, noe som:

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

En annen mulig bekymring er at FTP-servere returnerer tidsinformasjon i GMT (Greenwich Mean Time). Hvis serverens tidssone er kjent bortsett fra FTP-kommunikasjon, vil java.util.TimeZone.getOffset () metoden kan hjelpe til med å justere en dato mellom tidssoner. Se JDK-dokumentasjonen for ytterligere informasjon om denne metoden.

Avsnitt "Løsninger for gjenværende problemer" vurderer henting av filens tidsstempel videre.

Brannmurer

Vanligvis plasseres en brannmur mellom et privat bedriftsnettverk og et offentlig nettverk som Internett. Tilgang administreres fra det private nettverket til det offentlige nettverket, men tilgang nektes fra det offentlige nettverket til det private nettverket.

Sokker er en offentlig tilgjengelig protokoll utviklet for bruk som en brannmurgateway for Internett. JDK støtter Socks 4 og Socks 5 proxyer, som kan kontrolleres av noen av bibliotekene. Som et alternativ kan JVM-kommandolinjen angi sokker-proxy-parametere: java -DsocksProxyPort = 1080 -DsocksProxyHost = socks.foo.com -Djava.net.socks.username = user01 -Djava.net.socks.password = pass1234 ...

Et annet vanlig alternativ til Socks proxy-støtte er å "socksify" det underliggende TCP / IP-laget på klientmaskinen. Et produkt som Hummingbird kan gjøre den jobben.

JDK støtter også HTTP-tunneler. Disse utbredte fullmaktene tillater ikke FTP-opplasting. / n programvarens IP * Works lar deg sette HTTP-tunnelparametere.

De fleste biblioteker støtter både aktive og passive tilkoblinger: passiv tilkobling er nyttig når klienten står bak en brannmur som hemmer innkommende tilkoblinger til høyere porter. RFC1579 diskuterer denne brannmurvennlige funksjonaliteten mer detaljert. Noen produkters dokumentasjoner refererer til aktive og passive forbindelser som HAVN og PASV kommandoer, henholdsvis.

Parallell overføring

I en stasjonær applikasjon, når en overføring starter i hovedtråden, fryser alt. Noen biblioteker betjener automatisk hendelsessløyfen for parallelle overføringer i separate tråder, slik at vi ikke trenger å opprette og administrere våre egne tråder.