[120] in Information Retrieval
Re: ftp'ing TULIP data
daemon@ATHENA.MIT.EDU (Jerome H Saltzer)
Sat Nov 14 12:11:19 1992
Date: Sat, 14 Nov 1992 12:08:26 -0500
To: T Gregory Anderson <ganderso@MIT.EDU>,
From: Jerome H Saltzer <Saltzer@MIT.EDU>
>"Each University will provide Engineering Information with a host
>access account into which Engineering Information will login using
>FTP protocols and deposit all TULIP data."[under program control]
> - Project TULIP Technical Plan - Ei proposal of April 10, 1992
I predict that that method won't remain in place for long, once they find
out what they have let themselves in for. Push is fundamentally inferior
to pull; whoever designed the technical plan not have had the experience of
trying to make push to N places work. It is absolutely certain that at the
moment that the data is ready, a randomly selected 2 of the n places will
not correctly accept the data for some reason or another--network
connectivity down, file system overflow, timeout on the FTP connection,
designated host down for maintenance, recovering from a disk crash,
password has expired, or whatever. Either those two sites miss that
update, or else EI keeps track of the fact that the attempt failed and
retries those two sites until it works, despite an inability to fix the two
sites. But EI's incentive to keep trying is minimal; the initiative is in
the wrong place.
If, on the other hand, they mail an update notice, the mail system will
keep trying for up to three days. The mail path is one that receives a lot
of maintenance attention because when it is down everyone complains. So
the notice will very likely get through. The receiving sites would then
initiate FTP (pull) transfers at a time when they know they are prepared to
accomodate the data, and with an amount of initiative that each site
determines locally. And the local site doesn't have to worry about a
runaway program at the distribution site accidentally filling up the local
disk.
It will be interesting to watch this one evolve.
Jerry
