zlacker

>>saint1+(OP)
The author of this tool uploaded a YouTube video demonstrating it a few days ago: https://www.youtube.com/watch?v=15_-hgsX2V0

At one point in his demo, he uploads a file but terminates the upload more or less halfway. Then he begins downloading the file - which only progresses to the point it had been uploaded, and subsequently stalls indefinitely. And, finally, he finishes uploading the file (which gracefully resumes) and the file download (which is still running) seamlessly completes.

I found that particularly impressive.

>>skibz+M2
It's very impressive, particularly if you remember waking up to a failed download from the night before over dial-up.

>>nkrisc+S6
I recall we had special apps to queue and schedule our downloads, and resume them where servers supported it. They were a dream compared to the boredom of staring at progress bars.

>>paulry+5o
The server that has moved countless Petabytes is glFTPd that allows FXP ( clients without bandwidth can initiate to transfer files from server to server ).

>>Datage+DO
That’s a built-in feature of FTP that doesn’t require server support.

Edit: Source: https://en.wikipedia.org/wiki/File_eXchange_Protocol#Technic...

1. You connect to servers A and B.

2. Tell B to receive a PASV transfer. It replies with the IP address and port it's receiving on.

3. Tell A to send to that address and port.

This is documented in RFC 959, starting with

  "In another situation a user might wish to transfer files between two hosts, neither of which is a local host."