As per Relevance of the word exchange, we have this rfc below:
Network Working Group C.
Request for Comments: 1080 Rutgers
November 1988
Telnet Remote Flow Control
Status of This
This RFC specifies a standard for the Internet community. Hosts
the Internet that do remote flow control within the Telnet
are expected to adopt and implement this standard. Distribution
this memo is unlimited
This memo describes a method of remotely toggling flow
between a user telnet process and the attached terminal. Only
control of data being transmitted from the telnet process to
terminal is considered. Many systems will also allow flow control
data from the terminal to the telnet process. However there
seldom need to change this behavior repeatedly during the session
There are two common ways of doing flow control: hardware
software. Hardware flow control uses signals on wires dedicated
this purpose. Software flow control uses one or two
characters sent along the same path as normal input data.
commonly, XOFF (control-S) and XON (control-Q) are used to stop
start output, respectively. The option described herein is
primarily where software flow control is being used. (Since
flow control does not preempt any characters, there is normally
need to disable it.)
The primary difficulty with software flow control is that it
one or two characters. Host software often requires the user to
able to input every possible ASCII character. (Certain editors
notorious for having XOFF and XON as commonly-used commands.)
this reason, operating systems often allow programs to disable
control. While it is disabled, the characters that normally
flow control may be read as normal input. In a telnet environment
flow control is normally done by the user telnet process, not by
host computer. Thus this RFC defines a way to propagate flow
status from the host computer to the user telnet process
Hedrick [Page 1]
RFC 1080 Telnet Remote Flow Control Option December 1988
1. Command Name and
TOGGLE-FLOW-
Code = 33
2. Command
IAC WILL TOGGLE-FLOW-
Sender is willing to enable and disable flow control
command
IAC WON'T TOGGLE-FLOW-
Sender refuses to enable and disable flow control. Nothing
implied about whether sender does or does not use flow control
It is simply unwilling to enable and disable it using
protocol
IAC DO TOGGLE-FLOW-
Sender is willing to send commands to enable and disable
control
IAC DON'T TOGGLE-FLOW-
Sender refuses to send command to enable and disable
control
IAC SB TOGGLE-FLOW-CONTROL OFF IAC
Sender requests receiver to disable flow control. The code
OFF is 0.
IAC SB TOGGLE-FLOW-CONTROL ON IAC
Sender requests receiver to enable flow control. The code
ON is 1.
3.
WON'T TOGGLE-FLOW-
Flow control information will not be exchanged
Hedrick [Page 2]
RFC 1080 Telnet Remote Flow Control Option December 1988
DON'T TOGGLE-FLOW-
Flow control information will not be exchanged
4. Description of the
Use of the option requires two phases. In the first phase,
telnet processes agree that one of them will TOGGLE-FLOW-CONTROL
WILL and DO are used only in this first phase. In general there
be only one exchange of WILL and DO for a session.
must not be issued until DO and WILL have been exchanged. It
permissible for either side to turn off the option by sending a
or DONT. Should this happen, no more subnegotiations may be sent
unless the option is reenabled by another exchange of DO and WILL
Once the hosts have exchanged a WILL and a DO, the sender of the
TOGGLE-FLOW-CONTROL is free to send subnegotiations to enable
disable flow control in the other process. Normally, the sender
the DO will be a host, and the other end will be a user
process, which is connected to a terminal. Thus the protocol
normally asymmetric. However it may be used in both
without confusion should need for this arise
As soon as the DO and WILL have been exchanged, the sender of
WILL must enable flow control. This allows flow control to begin
a known state. Should the option be disabled by exchange of DONT
WONT, flow control may revert to an implementation-defined
state. It is not safe to assume that flow control will remain in
state requested by the most recent subnegotiation
Currently, only two command codes are defined for
subnegotiations: flow control off (code 0) and flow control on (
1). Neither of these codes requires any additional data. However
is possible that additional commands may be added.
subnegotiations having command codes other than 0 and 1 should
ignored
Here is an example of use of this option
Host1: IAC DO TOGGLE-FLOW-
Host2: IAC WILL TOGGLE-FLOW-
(Host1 is now free to send commands to change flow control
Note that host2 must now have enabled flow control.)
Hedrick [Page 3]
RFC 1080 Telnet Remote Flow Control Option December 1988
Host1: IAC SB TOGGLE-FLOW-CONTROL OFF IAC
Host1: IAC SB TOGGLE-FLOW-CONTROL ON IAC
Author's Address
Charles
Rutgers
Center for Computer and Information
Hill Center, Busch
P.O. Box 879
Piscataway, NJ 08855-0879
Phone: (201) 932-3088
Email: HEDRICK@ARAMIS.RUTGERS.
Hedrick [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
