ftp in java

[micro]

Hello,
I am developing java app that one of its functionality is to upload
and download from an ftp sever .
after googling it I found that is no official support to ftp in
original j2se packages .
there is class called sun.net.ftp but it is not fully supported or
tested.
I found many alternatives like:
Apache Commons Net
and
http://www.enterprisedt.com/products/edtftpj/

I am not very professional in ftp protocol and I don't know Pros and
Cons of each solution

please help

thank you in advance.

 

[Arne Vajhøj]

I am developing java app that one of its functionality is to upload
and download from an ftp sever .
after googling it I found that is no official support to ftp in
original j2se packages .
there is class called sun.net.ftp but it is not fully supported or
tested.
I found many alternatives like:
Apache Commons Net
and
http://www.enterprisedt.com/products/edtftpj/

I am not very professional in ftp protocol and I don't know Pros and
Cons of each solution

The builtin for the simple stuff (URL retrieval) and Commons Net
for the rest (except the enrcypted stuff) will do fine.

Arne

 

[softwarepearls_com]

I found many alternatives like:

Apache Commons Net

That's the one I used in the past, nice and sweet.

 

[Roedy Green]

I am developing java app that one of its functionality is to upload
and download from an ftp sever .

see http://mindprod.com/jgloss/ftp.html

there is quite a bit of third party FTP support. FTP is a very old
protocol and is on the way out. One problem with it is it does not
know what a timezone is. It does not deal properly with uploading
from one timezone to a server in another.

It does not preserve file dates.

It does not do atomic updates. On my site for example you will
sometimes see web pages without their images. You saw the site in the
middle of a an update. The images were not uploaded yet. You should
not see anything of an update batch until the entire batch is
uploaded.

FTP has no cleverness about avoiding material already uploaded.

FTP needs to be replaced. -- a possibility RSYNCH, Virtual drives.

 

[Arne Vajhøj]

there is quite a bit of third party FTP support. FTP is a very old
protocol and is on the way out.

It is not latest and greatest, but it will continue to be used
for many years to come.

One problem with it is it does not
know what a timezone is. It does not deal properly with uploading
from one timezone to a server in another.

It does not preserve file dates.

It does not do atomic updates. On my site for example you will
sometimes see web pages without their images. You saw the site in the
middle of a an update. The images were not uploaded yet. You should
not see anything of an update batch until the entire batch is
uploaded.

The protocol that has replaced FTP for many purposes (HTTP) does
not do these things either, so the problem does not seem to be
that big.

Arne

 

[micro]

is there a better protocol to upload files to server than FTP and
supported by java?
thanks alot to all of you

 

[Knute Johnson]

is there a better protocol to upload files to server than FTP and
supported by java?
thanks alot to all of you

FTP is an existing protocol. There are FTP servers and clients
available for every platform.

Transferring files is just a matter of copying bytes from one place to
another. I've written numerous programs to do that with Java. The real
question is what are you really trying to do? If you want to send files
to existing FTP servers then and FTP client would be the tool to use.
If you have a Java program and need to send files between two locations,
you can just make a connection and send the bytes. It isn't that
complicated. I wouldn't recreate what exists and I wouldn't hesitate to
write something simple to transfer files around.

 

[Mike Schilling]

FTP is an existing protocol. There are FTP servers and clients
available for every platform.

Transferring files is just a matter of copying bytes from one place
to
another. I've written numerous programs to do that with Java. The
real question is what are you really trying to do? If you want to
send files to existing FTP servers then and FTP client would be the
tool to use. If you have a Java program and need to send files
between two locations, you can just make a connection and send the
bytes. It isn't that complicated. I wouldn't recreate what exists
and I wouldn't hesitate to write something simple to transfer files
around.

FTP is highly optimized. If you're sending large files and
performance is important, it makes more sense to use FTP than to roll
your own file-transfer protocol, in Java or any other language.

 

[Arne Vajhøj]

is there a better protocol to upload files to server than FTP and
supported by java?

"better" is such an absolute term.

In some cases HTTP makes it easier to get through firewalls
and routers.

Arne

 

[Ove Gram Nipen]

Hello,
I am developing java app that one of its functionality is to upload
and download from an ftp sever .

I found many alternatives like:
Apache Commons Net
and
http://www.enterprisedt.com/products/edtftpj/

I use Apache Commons Net myself, and I think it's easy to work with. If
you only need your program to be able to upload and download files,
you'll achieve that with Commons Net. I haven't tried edtftpj.

I am not very professional in ftp protocol and I don't know Pros and
Cons of each solution

If what you're really trying to do is to write an integration solution,
where you for instance integrate two programs by moving files between
them or in any other way try to mediate the differences between two
programs so that they can communicate, you might want to take a look at
an integration platform such as mule.

- oven

 

[Arne Vajhøj]

To me the great advantage of HTTP is that it has a Content-Length
header, thus enabling the receiving application to know and perhaps
display progress. FTP is more like "we'll be done when we're done".

I don't see that as so useful, because it is not always present, so
one have to code for it not being there anyway.

Arne

 

[Christian]

FTP is highly optimized. If you're sending large files and
performance is important, it makes more sense to use FTP than to roll
your own file-transfer protocol, in Java or any other language.

In what sense is it optimized?

The Big problem is that FTP has no verification for files.
After transferring a file you never know if it has been transferred
without errors ... no hashing not even a stupid crc-check is done
imho FTP should die as soon as possible.
Its a danger to any files integrity.

Christian

 

[Arne Vajhøj]

In what sense is it optimized?

The Big problem is that FTP has no verification for files.
After transferring a file you never know if it has been transferred
without errors ... no hashing not even a stupid crc-check is done
imho FTP should die as soon as possible.
Its a danger to any files integrity.

HTTP is no different.

That type of check are usually done at a higher level than basic
file transfer.

Like first transferring both real file and checksum file, so the
real file can be verified.

Besides lots of files are transferred as ZIP files and then
ZIP provides CRC check.

Arne

 

[Tom Anderson]

I'd like to know that too. It's possible that FTP servers are optimised -
in fact, i'm sure they are. But then, so are HTTP servers. I don't believe
there's really any scope for optimising the protocol itself - TCP is TCP.

HTTP is no different.

That type of check are usually done at a higher level than basic file
transfer.

And lower - TCP has a checksum, as do pretty much all link-layer
protocols.

tom

 

[Arne Vajhøj]

And lower - TCP has a checksum, as do pretty much all link-layer protocols.

But that is on packets not on files.

Arne

 

[Mike Schilling]

In what sense is it optimized?

It's really, really fast. Multiple TCP connections, multi-buffering,
etc.

 

[Arne Vajhøj]

It's really, really fast. Multiple TCP connections, multi-buffering,
etc.

Only one connection for data transfer. That commands are on a separate
connection does not really make it more efficient.

Buffering is something in the FTP implementation - it is not something
described in the protocol and present in all implementations.

Arne

 

[Mike Schilling]

Only one connection for data transfer. That commands are on a
separate
connection does not really make it more efficient.

Buffering is something in the FTP implementation - it is not
something
described in the protocol and present in all implementations.

If you benchmark any standard FTP implementation against a naive "open
a TCP connection and send some bytes across" implementation, FTP will,
I assure you, be much faster. You can then start to optimize your
implementation, but why re-invent the wheel when FTP is already there?

Again, this assumes that performance is important. If not, the naive
implementation may be just as good for you.

 

[marlow.andrew]

FTP is a very old
protocol and is on the way out.

[some FTP defficiencies snipped]
Also, FTP sends usernames and passwords across the wire in plaintext.
That's why on some machines where security is taken seriously, FTP
daemons are not running, SFTP is used instead.

Regards,

Andrew Marlow

 

[Tom Anderson]

But that is on packets not on files.

True, but since the file is transferred in packets, it also covers the
file. Your TCP or HTTP/FTP implementation could put the packets together
wrongly, and that wouldn't be detected, of course, but that's a rather
hypothetical risk.

I'm not saying that file-level checksums aren't needed - they're a very
good idea, not least because the TCP checksum is very weak - just that
there is already a layer of checksumming here.

tom