Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!GYRE.UMD.EDU!chris
From: chris@GYRE.UMD.EDU (Chris Torek)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  oob in rlogin
Message-ID: <8810251946.AA11098@gyre.umd.edu>
Date: 25 Oct 88 19:46:39 GMT
Article-I.D.: gyre.8810251946.AA11098
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38

Joel A. Mussman (jam@radc-lonex.arpa) notes:

>OOB data is used to pass four flags to the client:
>
>	#define	TIOCPKT_FLUSHWRITE	0x02
>	#define	TIOCPKT_NOSTOP		0x10
>	#define	TIOCPKT_DOSTOP		0x20
>	#define	TIOCPKT_WINDOW		0x80
>
>Any others are ignored.

This is true, but only because the others are hard to implement in
the current Berkeley system.  There are three more:

	#define	TIOCPKT_FLUSHREAD	0x01

This is intended to throw out typeahead.  Only that typeahead which
was present when the out of band data itself was sent should be discarded;
since there is no way to tell when that was, the current rlogin client
ignores this.

	#define	TIOCPKT_STOP		0x04	/* stop output */
	#define	TIOCPKT_START		0x08	/* start output */

Upon receiving a STOP, the client should stop copying output, and
should cause the local tty device to stop producing output, but *not*
stop receiving; the client should resume output (without dicarding
anything) upon receiving a START.  Servers should never send both STOP
and START in the same OOB data, but if it happens I suspect the proper
action is to resume if currently stopped, and otherwise to do nothing.

Stop and start ought to be unnecessary, but the DOSTOP/NOSTOP protocol
only accomodates ^S/^Q flow control.  Positive flow control (ENQ/ACK
and the like) does not need STOP and START, but negative flow control
using characters other than ^S/^Q will in fact generate STOP and START
requests.

Chris