home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / dcom / modems / 19030 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  3.1 KB
  1. Path: sparky!uunet!ogicse!mimbres.cs.unm.edu!constellation!a.cs.okstate.edu!jmccorm
  2. From: jmccorm@a.cs.okstate.edu (MCCORMICK JOSHUA C)
  3. Newsgroups: comp.dcom.modems
  4. Subject: RE: Zmodem and RTS/CTS handshaking
  5. Message-ID: <1993Jan6.202035.1397@a.cs.okstate.edu>
  6. Date: 6 Jan 93 20:20:35 GMT
  7. Article-I.D.: a.1993Jan6.202035.1397
  8. Organization: Oklahoma State University, Computer Science, Stillwater
  9. Lines: 57
  10.  
  11. Newsgroups: comp,.dcom.modems
  12. Subject: RE: RTS/CTS handshaking reply
  13. Organization: Oklahoma State University, Computer Science, Stillwater
  14.  
  15. I was sent some email concerning RTS/CTS handshaking an a problem with
  16. ZMODEM by RJS. I was unable to determine the return address, so here is
  17. your reply:
  18.  
  19. >   I have a follow-on question for you:  if the problem is RTS/CTS,
  20. > why does it only show up when using zmodem protocol and not x- or
  21. > ymodem?  
  22.  
  23. Zmodem is what's called a streaming protocol. That is, it just sends and
  24. sends data, without stopping, unless the other end tells it there is a 
  25. problem. In the case of Ymodem or Xmodem, they send a predetermined block
  26. size (usually 1k for Ymodem, 256 bytes for Xmodem). Since Ymodem and Xmodem
  27. sends a block size that is under your modem's buffer size, then stops and
  28. waits for an acknowledgement before sending another block, your buffer isn't
  29. overflowed. But Zmodem will send and send data. Your modem realizes that
  30. your buffer is going to be overflowed and screams to your computer "Stop!
  31. Stop!" with the handshaking lines. But if your modem or your terminal
  32. software is not correctly set up, Zmodem will never get the message and
  33. it'll keep on sending data, trashing what's in your modem's buffer in the
  34. process. Your terminal software will claim to be getting phenominal CPS
  35. rates, but you'll notice that it's getting nowhere fast.
  36.  
  37. >   And why do you reecommend XON/XOFF be disabled?
  38.  
  39. The XON/XOFF handshaking protocol expects ^Q and ^S to be inserted into
  40. the data stream in order to tell the modem (or your terminal) when to
  41. stop sending data. Imagine doing a Zmodem upload and suddenly you start
  42. receiving ^S's in the middle of a transfer. You'll be in the exact same
  43. boat you are now, since your terminal won't understand the significance
  44. of what it is receiving, and it'll fool the protocol into thinking there
  45. are addition errors. Likewise, if there is a ^S in the data you are
  46. sending (which is common in non-text files), then your modem will stop
  47. sending data at random during a file transfer. Nasty stuff. XON/XOFF
  48. handshaking protocol is not commonly used in the PC world.
  49.  
  50. >  Last question: how is a modem set up to send the proper
  51. > handshaking signals?  AT command in the init string, or set a value
  52. > in one of the  S-registers?
  53.  
  54. It varies from modem to modem. In my Practical Peripherals PM1440FXSA, which
  55. is 99.5% compatible with the Hayes _high speed command set_ (which is not
  56. standardized throughout the industry like the normal command set), I believe I
  57. have AT&D set to 2... [AT&D2 command]. But, this will vary from modem to
  58. modem.
  59.  
  60. If you fix your handshaking protocol, you shouldn't have any problem with
  61. Zmodem uploads, and a few other minor problems which can pop up from time
  62. to time.
  63.  
  64.  
  65.  
  66.  
  67. j
  68.