As per Relevance of the word incoming, we have this rfc below:
Network Working Group V.
Request for Comments: 794
Replaces: IEN 125 September 1981
PRE-
In circuit-switching systems, once a user has acquired a circuit,
communication bandwidth of that circuit is dedicated, even if it is
used. When the system saturates, additional circuit set-up requests
blocked. To allow high precedence users to gain access to
resources, systems such as AUTOVON associate a precedence with
telephone instrument. Those instruments with high precedence
pre-empt circuit resources, causing lower precedence users to be
off
In message switching systems such as AUTODIN I, incoming traffic
stored on disks (or drums or tape) and processed in order
precedence. If a high precedence message is entered into the system,
is processed and forwarded as quickly as possible. When the
precedence message arrives at the destination message switch, it
pre-empt the use of the output devices on the switch, interrupting
printing of a lower precedence message
In packet switching systems, there is little or no storage in
transport system so that precedence has little impact on delay
processing a packet. However, when a packet switching system
saturation, it rejects offered traffic. Precedence can be used
saturated packet switched systems to sort traffic queued for entry
the system
In general, precedence is a tool for deciding how to allocate
when systems are saturated. In circuit switched systems, the
is circuits; in message switched systems the resource is the
switch processor; and in packet switching the resource is the
switching system itself
This capability can be realized in AUTODIN II without adding any
mechanisms to TCP (except to make precedence of incoming
requests visible to the processes which use TCP). To allow pre-
access to a particular terminal, the software (i.e., THP) which
terminal access to the TAC can be configured so as to always have
LISTEN posted for that terminal, even if the terminal has a
in operation. For example in the ARPANET TENEX systems, the user
permits a user to have many connections open at one time - the user
switch among them at will. To the extent that this can be done
violating security requirements, one could imagine a multi-
THP which always leaves a LISTEN pending for incoming
requests. If a connection is established, the THP can decide, based
its precedence, whether to pre-empt any existing connection and
switch the user to the high precedence one
If the user is working with several connections of different
at the same time, the THP would close or abort the lowest
Cerf [Page 1]
September 1981
Pre-
connection in favor of the higher precedence pre-empting one. Then
THP would do a new LISTEN on that terminal's port in case a
precedence connection is attempted
One of the reasons for suggesting this model is that processes are
users of TCP (in general) and that TCP itself cannot cause processes
be created on behalf of an incoming connection request.
could be realized in which TCPs accept incoming connection requests and
based on the destination port number, create appropriate
processes. In terms of pre-empting access to a remote terminal
however, it seems more sensible to let the process which interfaces
terminal to the system mediate the pre-emption. If the terminal is
connected or is turned off, there is no point in creating a process
serve the incoming high precedence connection request
For example, suppose a routine FTP is in operation between Host X
Host Y. Host Z decides to do a flash-override FTP to Host X. It
a high precedence connection via its TCP and the "SYN" goes out to
FTP port on Host X
FTP always leaves one LISTEN pending to pre-empt lower precedence
users if it cannot serve one more user (and still keep a
pending). In this way, the FTP is naturally in a state permitting
high precedence connection request to be properly served, and the
can initiate any cleaning up that is needed to deal with
pre-emption
In general, this strategy permits the processes using TCP to
pre-emption in the context of the applications they support
A non-pre-emptable process is one that does not have a LISTEN
while it is serving one (or more) users
The actions taken to deal with pre-emption of TCP connections will
application-process specific and this strategy of a second (or N+1st
LISTEN is well suited to the situation
Pre-emption may also be necessary at the site initiating a
precedence connection request. Suppose there is a high precedence
who wants to open an FTP connection request from Host Z to Host X.
all FTP and/or TCP resources are saturated when this user tries to
the user FTP process. In this case, the operating system would have
know about the precedence of the user and would have to locally pre-
resources on his behalf (e.g., by logging out lower precedence users).
This is a system issue, not specific only to TCP. Implementation
pre-emption at the source could vary greatly. Precedence may
associated with a user or with a terminal. The TCP implementation
locally pre-empt resources to serve high precedence users.
operating system may make all pre-emption decisions
[Page 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
