home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 10997 < prev    next >
Encoding:
Text File  |  1992-07-22  |  1.6 KB  |  43 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!decwrl!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: Boom! Our lawyers are tougher than your lawyers. You're Dead.
  5. Message-ID: <nktpnuk@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <1992Jul17.035105.6535@ddsw1.mcs.com> <BrsyEw.Dst@wsrcc.com>
  8. Date: Thu, 23 Jul 1992 03:30:54 GMT
  9. Lines: 32
  10.  
  11. In article <BrsyEw.Dst@wsrcc.com>, wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes:
  12. > 
  13. > This has nothing to do with "good modem manufacturers".  Anyone
  14. > relying on "<pause>+++<pause>" not occurring during a data transfer is
  15. > not writing good defensive code.  Good programmers don't *hope* that a
  16. > certain set of characters and delays never happens.  They turn off the
  17. > inband +++ escape kludge and use a good *out-of-band* escape.
  18.  
  19.  
  20. YES!
  21. That bears repeating.
  22.  
  23.  
  24. When two computers are talking, why should "<delay>+++<delay>" be
  25. usefully less likely than any other sequence of 3+2*<delay> bytes or 
  26. byte-times?
  27.  
  28.  
  29. You usually don't see pauses at random places in the middle of file
  30. transfers.   You usually see them at "record boundaries".  However,
  31. "usually" is a pretty sloppy way to design something.
  32.  
  33.  
  34. The "<delay>+++<delay>" thing seemed wrong to me for UUCP links when I
  35. first saw it years ago, when I started turning it off on all machines I
  36. could affect.  I have just now realized that I had forgotten that I'd
  37. tired of arguing from that position with people who don't care about
  38. the differences among "usually", "never", or any other probability, and
  39. have used the security argument.
  40.  
  41.  
  42. Vernon Schryver,  vjs@sgi.com
  43.