ftp in java

[Christian]

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.

I can assure you from my experience that ftp is not faster.
Except you really messed up your implementation. (like using MiB sized
Buffer)

FTP is not more than a old protocol that should be forgotten.
It has the same kind of usefullness as MD5 .. its used but not
recommendable if you have the choice.

The Problem is that we seem really to miss good ,simple widespread
public protocols for filetransfer.
Bittorrent would be nice though its neither simple nor anything else.
HTTP/FTP/SCP just seem to work fine enough and not corrupt files often
enough when used only on LAN.

In my homenetwork I already used successfully DirectConnect protocol for
filetransfers. As it checks files and is fast.
Though DC is not simple enough to incorporate into some Application.

Christian

 

[Christian]

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

its 2 Layers..
and IP checksums will be removed in the future (IPv6 may be I will live
that long until it really comes to the homeuser).

Experience shows that filechecksums are needed because of misbehaving
NATs and misbehaving firewalls.
Some of these devices try to replace IPs in the data packages.
Also Zone Alarm 4 for example had some problems with corrupting package
data.


Filechecksums is a must.
Nice is to have some interleave level of a merkletree so only parts of
the file have to be redownloaded again.


Christian

 

[Tom Anderson]

its 2 Layers..

Well, or a thick layer, depending on how you look at it .

and IP checksums will be removed in the future (IPv6 may be I will live
that long until it really comes to the homeuser).

The checksum is in TCP, not IP. IPv6 will make no difference to TCP's
checksumming, as far as i know.

Experience shows that filechecksums are needed because of misbehaving
NATs and misbehaving firewalls. Some of these devices try to replace IPs
in the data packages. Also Zone Alarm 4 for example had some problems
with corrupting package data.

Good point.

A way to get round this would be to use an encrypted protocol like HTTPS
that the middleboxes can't interfere with. Also, TLS, which is the secure
component of HTTPS, includes message authentication codes, which are a
kind of checksum.

Filechecksums is a must. Nice is to have some interleave level of a
merkletree so only parts of the file have to be redownloaded again.

Yes, that's a pretty cool approach.

tom

 

[Martin Gregorie]

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

Depends what you're using it for. If you're uploading/downloading files
from a public server it works well and is a well-known and supported file
transfer protocol and can be used from behind a firewall in so-called
passive mode (the client makes both the control connection and data
transfer connections, so you don't need any firewall holes). However,, as
has been pointed out elsewhere, everything you transfer (user names,
passwords and files) are transferred in plaintext and so can become
public knowledge.

If any of these items should not be public knowledge, consider using
sftp, which encrypts everything that is transferred. These days ssh has
replaced telnet for the same reason, so many (most?) hosts will run an
ssh server which can handle ssh (the telnet replacement interactive
connection as well as sftp (a close workalike for ftp) and scp (file at a
time like rcp).

Java implementations can be found at:
OpenSSH - http://www.openssh.com/java.html
SSH for Java - http://linuxmafia.com/ssh/java.html

 

[Arne Vajhøj]

True, but since the file is transferred in packets, it also covers the
file.

Not really.

> 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.

That is not the only thing that could go wrong.

If the server closes the data connection early all the TCP
checksums would be fine even though you only have a half file.

The content could get corrupted between file and packet in
both ends.

A checksum only verifies what it is checksumming.

Arne

 

[David R Tribble]

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".

FTP has something similar, the "ALLO" command, which preallocates
space for a received file (and is optional, of course).

FWIW, I wrote my own simple FTP implementation in Java:
http://david.tribble.com/src/java#tribble.net.ftp
http://david.tribble.com/docs/tribble/net/ftp/package-summary.html

-drt