Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site watcgl.UUCP Path: utzoo!watmath!watcgl!dmmartindale From: dmmartindale@watcgl.UUCP (Dave Martindale) Newsgroups: net.dcom Subject: Re: XON/XOFF as flow control? Message-ID: <1063@watcgl.UUCP> Date: Thu, 10-Nov-83 01:08:45 EST Article-I.D.: watcgl.1063 Posted: Thu Nov 10 01:08:45 1983 Date-Received: Fri, 11-Nov-83 06:13:18 EST References: <3636@umcp-cs.UUCP> Organization: U of Waterloo, Ontario Lines: 26 I can show how XON/XOFF flow control doesn't work over a network. Assume the terminal has a 32 character input FIFO. Now, the host writes a long escape sequence or whatever. Terminal sends an XOFF at 16 characters in FIFO. XOFF has to go over effective baud net connection, while terminal<->net connection is at least 2 baud. Unfortunately, the XOFF must have a packet constructed for it. This packet has a 40 byte header. Meanwhile, the next string written at the host is still coming across the connection (ie maybe 20 of those 40 header bytes have got through already with a large (20 character) text stream in the packet. By the time the host receives the XOFF, the entire 20 character packet has already gone through the net connection, and overflowed the FIFO. Of course, this problem goes away if you do the handshaking at the local net connection instead of the remote. Two comments: Of course you have to do the handshaking at the local connection to the net. Handshaking between the terminal and the host just doesn't work, since you can have arbitrarily long delays between one and the other (if the network is very busy, if the packet has to physically travel through several networks and gateways, etc.) 32 characters is an absurdly small input buffer, completely ridiculous. Even a basic, dumb 24x80 terminal needs 1920 bytes of screen memory. 100 chars of input buffer will not affect costs appreciably.