gandrews@netcom.COM (Greg Andrews) (04/30/91)
In article <1991Apr29.193312.16542@agate.berkeley.edu> labc-1ic@e260-1f.berkeley.edu (Willy S. Liao) writes: > >Anyway I do recall reading in my modem manual that xmodem absolutely does >not work without XON/XOFF flow control, so this implies it will never work >with MNP 5 & RTS/CTS. > I'm afraid that's not the case. Xmodem will work with transparent forms of flow control just fine (i.e. RTS/CTS). It's the non-transparent forms of flow control (i.e. XON/XOFF) that give it trouble. Since Xmodem and its close relatives (Xmodem-1K, Ymodem, Ymodem-G) use raw binary characters as block numbers, as soon as you attempt to send block #17, an XON character will appear in the data stream seen by the modem. Most modems will swallow the XON, thinking it's a flow control command and not data. Even if the modem passes the XON through, two blocks later you'll get a XOFF character as the block number. What's the poor modem to do? You told it to obey XON/XOFF flow control, so now it must stop feeding the Xmodem ACKs back to the sender, and the protocol halts. No fun. Xmodem also doesn't 'protect' the file data, it simply transmits the file contents as-is through the modems. If the data is non-ASCII (not composed of just the printable characters), such as executable programs or compressed files, then one of the file bytes may be an XON or XOFF, causing the same kind of trouble. When the modem is using RTS/CTS flow control, it's not interpreting characters as Stop/Start commands. It's watching the RTS pin (pin 4) to get its flow control commands. The data passes through without being misinterpreted by the modem. The trick is getting some systems to use RTS/CTS flow control... -- ------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'