home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / 5086 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.5 KB
  1. Path: sparky!uunet!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!tm8t+
  2. From: tm8t+@andrew.cmu.edu (Tod McQuillin)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: Transfer of 100's of MBytes files
  5. Message-ID: <8eyndsC00XQDELNoRM@andrew.cmu.edu>
  6. Date: 6 Nov 92 17:39:36 GMT
  7. Article-I.D.: andrew.8eyndsC00XQDELNoRM
  8. References: <rjberke.38.0@berke.itg.ti.com>
  9. Organization: Carnegie Mellon, Pittsburgh, PA
  10. Lines: 46
  11. In-Reply-To: <rjberke.38.0@berke.itg.ti.com>
  12.  
  13. rjberke@berke.itg.ti.com (Richard Berke) writes:
  14. > How often (1 out of 20?) do you run into aborted transfers that 
  15. > have to be restarted from scratch?
  16.  
  17. Pretty often.  Especially with large files transferred over a SLIP
  18. link.  I'd say 1 out of 50 times over SLIP, and 1 out of 200 on more
  19. permanent connections.
  20.  
  21. >                      Have you been able to distinguish
  22. > what portion of those failures are due to disk issues, circuit failures,
  23. > or protocol implementations?
  24.  
  25. In my experience, TCP is an extremely reliable protocol.  Aborted
  26. transfers are almost always caused by network hardware problems, or
  27. routing difficulties.
  28.  
  29. > I am frequently asked about the reliability of using FTP to move
  30. > files and/or sets of files that are 200-400 Mbytes, and there's interest
  31. > in some means of recovering from a disruption in the middle of a transfer.
  32.  
  33. You can always check that the transfer was successful by taking the
  34. checksum of the data on both ends.  The more recent implementations of
  35. the FTP protocol I've seen all support the "reget" command (I believe
  36. the FTP spec calls this "RETR") which allows you to resume an
  37. interrupted transfer.  I use it all the time and have never had a
  38. problem with it.
  39.  
  40. > I'm sensitive to disruptions, but wary of exotic schemes to recover.
  41.  
  42. I'd hardly call the reget command exotic.
  43.  
  44. > Since our world-wide links are as small as 56 Kbits/sec, transmission times
  45. > are significant.  Good throughput for FTP (not best case) is about 5 Kbytes
  46. > per second.  200-400 Mbytes takes 1-3 hours or more.  Detection of failed 
  47. > transfers may be delayed, further adding to wall clock time taken to 
  48. > accomplish the overall transfers.
  49.  
  50. You have a point there.  The reget command does not automatically work
  51. -- you have to type it yourself.
  52.  
  53. > I've heard that protocols exist for transfers that use checkpoints and 
  54. > can restart.  I've never heard of mainstream suppliers for them.
  55. > Are they available?  How necessary are they, compared to FTP?
  56.  
  57. I've never had a need for something like this, but then, it sounds
  58. like your data-moving requirements are more demanding than mine.
  59.