ggm@brolga.cc.uq.oz (George Michaelson) (12/18/89)
ftp doesn't seem to have any concept of unreliable underlying transport
or link. I would dearly love to see something like UK-NIFTP's partial
file transfer recovery in ftp. (in fact, I believe most uk-niftp don't
implement file xfer recovery and rewind the retransmission back to the front)
Once you start looking at that sort of functionality, you might wind up
agreeing with the OSI reference model which (i think) puts it in session level
but given a null session layer you dont have that choice.
I guess I'd rather see suitable code in an underlying layer, so that the same
functionality was available to ALL TCP-based services, nntp-over-slow-lines
and other bulk transfer being obvious candidates. I'm not (quite) silly
enough to see everyone hacking their kernel, and nobody is offering invisble
glue between TCP and the services, so I guess its a per-service addition or
nothing.
Why bother?
(1) bandwidth is scarce in several crucial places
cross-channel links
atlantic links
pacific links.
(2) Point-to-point links are NOT decreasing, SLIP to small boxes
and dial-in IP are increasing and thus "noisy" links are
just as common dispite backbone upgrades and other net-level
advances.
(3) IP based services aren't going away for years to come.
(4) OSI services can provide this functionality and it might
be nice to be able to bridge into Internet services and get
the same thing. [err.. can they? I *think* they can...]
ACSnet has partial transfer recovery built into the transport(ish) level
as well as a multiplexed link level. This is *extremely* useful and far
outweighs in my opinion the other (mis?)features of this package/protocol.
With its probable demise as the "backbone" protocol across Australia I suspect
we are going to see much WORSE service until people learn how to use the IP
based services "properly", ("manual" CSMA-CD when slow IP detected a.k.a try
again at 3am)
Question(s):
[history] Was partial transfer recovery considered? If so, why was it
rejected? I heard arguments against its implementation on
JANET such as "too hard" and "doesn't make sense between
divergent h/w or opsys" neither of which I think make sense,
especially given machine-independant upper-level encodings
like compressed-batch/lempel-ziv/NNTP and hop-based services
where you are placed in the role of an intermediate carrier.
[whinge] Is it sensible/possible to extend existing product(s) to provide
this function? We see Telnet and other extensions, PEP is out,
clearly The RFCs aren't rolling over and dying yet. Too late to
add into ftp? can it make 4.5bsd?
[cringe] Will people be using this feature in OSI applications? does it
get turned on automatically or is it missing from most existing
setups and thus impossible to use in MHS/FTAM over slow/noisy
lines?
Enquiring mind wants to know!
-George
Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
Queensland University, St Lucia, QLD Australia 4067.