Subj : A TCP/IP variation of -N
To : Mike Luther
From : David Noon
Date : Mon Aug 27 2001 10:48 am
Hi Mike,
Replying to a message of Mike Luther to David Noon:
DN>> This means that ftp itself does not need any real modification --
DN>> just smarter servers. I offered the U.K. mirror of Hobbes as an
DN>> example, but it uses Web pages to offer the zip file's contents for
DN>> selection. While http is somewhat slower than ftp, the difference
DN>> over a cable modem is sod all.
ML> You are totally correct, Dave, And the reason I didn't go forward
ML> with what was offered there, is that it seems it's more civilized to
ML> kick things around here in Fido, so I'll try to do that.
I agree: Fidonet is far more civilized than Usenet.
ML> The problem, as I see it is in that last sentence you offered:
DN>> While http is somewhat slower than ftp, the difference
DN>> over a cable modem is sod all.
ML> Under the conventional way of handling FTP for information and data
ML> recovery, we can recover a PAGE or PAGES of data.
I don't understand this. ftp shifts entire files around. Did you mean http?
ML> When we see it
ML> displayed on the download end, it is what is in the PAGE that is what
ML> we see, Since the content in the page is accurate, the underpinning
ML> file that is a part of it is transparent to the user, but is *NOT*
ML> the same. It does not have the same date and time stamp as the
ML> source.
That depends on the ftp client embedded in your Web browser.
ML> HTTP has no underling method, which I know about, to match the file
ML> date and time stamp between the systems,
http is used for the interactive part: selecting the zip file to have its
directory listed, and to make selections from the list. The transfer should
then be done by ftp, which should also preserve the file's timestamp.
ML> file, or record, as a result of its file stamp time. We absolutely
ML> have to maintain file stamp date and time,and, yes, in some case,
ML> even the EA's, just to precisely match the information package
ML> between the boxes!
Now EA's *do* present a problem.
[snip]
What you are asking for is a form of journalling and recovery using ftp, or
some moral equivalent. Moreover, you need this processing to be so water-tight
that it will keep the FDA [and other government departments around the world]
happy as to its accuracy. This is a job for which ftp is not really suited.
Data recovery from journals is a task that is best handled by a program that
makes the recovery as automatic as possible. This program could use TCP/IP
sockets for its "network tape silo" instead of conventional tape [or other
backup] media. But its real smarts have to be in the way the files to be
recovered are identified. This should require as little human interaction as
possible. The upshot is that some script wrapping an ftp client is like using
chewing gum and string where high tensile steel is required.
The reason for this is that the DASD farm of the system to be recovered should
not be trusted. Any client system that has been compromised is really
untrustworthy. This includes the accuracy of file timestamps. The definitive
source of such information should be the journals on the recovery server. This
means that the recovery server drives the entire operation.
Data propagation can be handled using the same tools. The journalling activity
can be used to propagate files automatically as they change. The recovery
utility can be used to rebuild one system on another machine by making the
recovery parametric: change the parameter that identifies the "lost" system,
rather than run with the current system's id.
For none of this is ftp a really suitable tool.
And that's one reason why Lotus Notes costs an arm and a leg!
Regards
Dave
<Team PL/I>
--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)
