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 --- FleetStreet 1.25.1 * Origin: My other computer is an IBM S/390 (2:257/609.5) .