As per Relevance of the word handling, we have this rfc below:
Network Working Group Jon Postel (SRI-ARC
Request For Comments: 718 Jun 1976
NIC #35874
The following memo was a page of a document describing changes
version 1.34 of the Tenex system. I believe that the author is
Tomlinson or someone else in the BBN-RCC Tenex group. In any case
has agreed that these comments should be circulated to the to
network community, rather than to only the Tenex community
Comments on RCTE from the TENEX Implementation
The code to implement the RCTE option of the new TELNET protocol
TENEX has been completed. The RCTE option permits a reduction in
traffic by deferring the transmission of characters which will not
the receiving user program to be activated until a character which
cause the user program to be activated. A further reduction is
by minimizing the flow of echo characters back to the user
program. This is done by having the server instruct the user TELNET
echo the group of characters up through the next wakeup character.
sending this command as the user program is about to read the
character of that group, the echo is guaranteed to follow any
to the preceding group of characters
Significant problems with the RCTE protocol were encountered.
handling of spontaneous output was specified in a way that made
implementation extremely difficult to do correctly (if, indeed,
correct implementation is possible). The solution here was to
isolate the control of input transmission and echoing from
characters flowing in the output stream. Synchronization of input
output then occurs directly by virtue of the embedding of
information in the output stream. This approach permits a
coding of both the user TELNET and server TELNET
A second problem was the handling of interrupt characters. The
protocol fails to provide an explicit mechanism for interrupt
thus necessitating the handling of interrupt characters as
wakeup characters. Since the interrupt characters are not
handled as program wakeup characters and, in fact, bypass the
input buffer, a special provision had to be made to get the command
back to the user TELNET to indicate that the character stream should
echoed beyond the point where the interrupt character was typed.
transmission must be synchronized with the processing of the
input buffer so that it will be sent at the proper time. This
achieved by putting a marker in the input buffer at the point where
interrupt character was. This marker is never given to the user'
program and must not be counted as an input character. A new counter
installed indicating the number of such markers in the input buffer
the SIBE JSYS modified to indicate "empty" only if the difference of
total characters in the buffer and the number of markers in the
is greater than 0.
-1-
A third problem is handling the case where the input buffer is cleared
Since the buffer may contain various wakeup characters and
markers, when the buffer is cleared, the user TELNET and SERVER may
out of sync. It is infeasible to scan the buffer and send a
command for each such wakeup character or special marker. instead,
command is sent to the user TELNET meaning "clear your input buffer
reset your counters". This command is implemented by sending "
RCTE". This is the reverse case from a normal RCTE (i.e. DO RCTE)
thus cannot be confused with the normal use of the RCTE option.
saves adding a new option
-2-
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
