Text 995, 58 rader
Skriven 2007-05-15 01:07:24 av Matt Bedynek (1:106/1)
    Kommentar till text 869 av andrew clarke (3:633/267.0)
Ärende: binkp vs ftp
====================
Hello andrew.

04 May 07 16:59, you wrote to Maurice Kinal:

 ac> They aren't supposed to.  But FTP isn't designed to transfer FidoNet
 ac> mail.  In particular, there's no reliable mechanism for FTP servers to
 ac> truncate or delete mail bundles after they've been sent to another
 ac> node.  Unlike a BinkP client, an FTP client has no way to acknowledge
 ac> that it received a file.

FTP can work reliably.  I used it to move far larger volumes of mail than I do
today and never lost anything.  It requirse an intelligent ftp client and
server configuration.  In fact, I still have one link that uses FTP.

Server side:

1) Using the old arcmail naming convention, there is a limited number of bundle
names available.  So, I move mail from the BSO about once an hour as to use up
all the names across a 24 hour period.

2) The user is supposed to create a busy flag when they connect so my tools do
not touch their home directory when they are online retreving mail.

3) When my script runs, it creates a BSO busy flag before moving the bundles
from the BSO.  After a bundle is moved, it is truncated like a mailer would so
the names incrememnt.

4) Mail over 6 days is deleted for obvious reasons.

Client side:

1) Does not delete files remotely until after sucessfully retreiving it.

2) Creates the busy file on the ftp server.

3) Auto renames incoming file if a file by that name already exists (much like
binkd does).

4) Auto renames files on the destination if a file by that name exists.

For OS/2, FIFTP was the best ever (hands down).  It could upload and download
at the same time, had resume, and was very reliable.  It was unfortunately it
was never made open source.

I coded a variety of ftp clients over the years to do much like the above in
REXX and Perl.  As well as server side handling scripts.  Most of the problems
I've seen with implementations of FTP were poor server implementation of FTP
standards or operators not correctly setting up their server with respect to
firewalls.  FTP was not really designed to play well with firewalls.  It
requires lots of overhead (as you know).  In retrospect, http would have
actually been a better option since it only needs one port for communication.

Matt

em: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

---
 * Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)