As per Relevance of the word connection, we have this rfc below:
Network Working Group Edward Taft (PARC-MAXC
Request for Comments: 617 Feb 1974
NIC #21771
A Note on Socket Number Assignment 2
In several current and proposed protocols, as well as in a
other documents, the assumption is made (or implied) that a
process in control of one end of a Telnet connection has
access to a group of socket numbers beginning with or
the Telnet socket numbers
For example, the File Transfer Protocol (RFC 542, NIC #17759)
specifies that the default data transfer sockets are S+2, S+3,
U+4, and U+5, where S and U are the server and user
involved in the initial connection (ICP).
Similarly, the proposed Network Graphics Protocol (NIC #19933)
provides for a second connection pair for graphics data
parallel to the Telnet connection, using (at both ends)
n+6 and n+7, where n is the Telnet receive socket
I would like to point out to designers of protocols that
Host-Host Protocol (NIC #8246) quite explicitly places
interpretations or constraints on host assignment of
numbers, except for the use of the low-order bit to
direction of data flow. We should refrain from making
assumptions (as does the "Socket Number List" document (RFC 503,
NIC #15747) in stating that the low-order 8 bits
"user-specified"), lest we inadvertently exclude certain
software architectures or protocol implementations
AN
To illustrate the source of my concern, let me briefly
the user software interface to the network in the PDP-10
implementation currently in use at HARV-10, CMU-10A, and CMU-108.
I will then show why the fixed socket number requirements of
two protocols I mentioned above present
difficulties, especially at the server end
Opening a connection at one of these hosts causes the creation
a "device" (in approximately the same manner as, say, mounting
disk pack). As such, an open connection is subject to any one
a number of operations on devices in 10/50, including
of logical names, opening for data transfer, and reassignment
another job
-1-
The NCP allows a (non-privileged) user program to specify
low-order 8 bits of the socket number of any connection which
opens, and to specify that the other 24 bits be assigned in one
three ways
-- As a function of the job number, making a "job-relative
socket
-- As a function of the user identification, making
"user-relative" socket
-- As a "guaranteed unique" number, i.e. one assigned by
NCP such that no other socket number in use has the
high-order 24 bits
A program may also specify all 32 bits of a local socket
provided the high-order 24 bits are the same as the
bits in some other socket already owned by the same job
The NCP will, of course, allow assignment of a socket generated
any of the above ways only if it is not already in use by the
or any other job
PROBLEMS IN THE FTP SERVER IMPLEMENTATION 5
The FTP server is implemented in a manner that some readers
find reminiscent of Padlipsky's "Unified User Level Protocol" (
451, NIC #14135). Rather than directly executing most
functions (in particular, system access and file
functions), it merely maps FTP commands into local commands
it "types" on a pseudo-Teletype (PTY) to a subjob, and
maps local responses into FTP responses
This scheme makes maximum use of existing software
mechanisms for user authentication, accounting, and
access, and eliminates the need for the (privileged) FTP
to perform them interpretively. (This conforms to
"principle of least privilege" described in RFC 501,
#15818.)
In this implementation, FTP data transfers are performed by
entirely different process (with a different user identification
from the one that manages the server end of the Telnet connection
Hence, since server sockets S and S+1 belong to the
"control" job and sockets S+2 and S+3 are in the same 256-
number range, the latter two sockets are inaccessible to the "
transfer" subjob
-2-
Those who attended last spring's FTP meeting may recall that
objected strenuously to the requirement that the FTP server
a fixed pair of data sockets relative to its Telnet sockets,
opposed to the old scheme in which the server has
freedom in the choice of its data sockets. The
reason is that it would seem to rule out the "two-process
scheme I have just described
In fact, in our case there is a way around the problem.
FTP server control job can open the data connections itself
then "reassign" the created "device" to the data
subjob. A kludgey solution at best, and one I would
have avoided! Inter-job socket reassignment is hardly
operation one is likely to find available in most
systems
DIFFICULTIES WITH THE GRAPHICS
Providing a graphics connection parallel (at a fixed socket
distance) to the Telnet connection might potentially present
same difficulty as described above for FTP connections
In the most frequently used model of Telnet communication,
well as in many implementations, the server Telnet is a
quite distinct from the "user" process under its control.
two processes are typically interfaced through the
system's terminal service in such a way that the "user"
perceives a ,terminal" as opposed to a "network connection".
In Tenex, for example, a job controlled from a
terminal has no handle whatever on the server
connection; hence, it has no way of obtaining control
sockets n+6 and n+7 for a graphics connection
In the Harvard-Carnegie 10/50 implementation, it happens (
largely accidental reasons) that a job logged in from
network does have control (i.e. is considered the owner) of
server Telnet sockets
However, there is another problem. Many operating systems
means by which the association between terminals and jobs may
changed
To use familiar terminology, a terminal may be "detached"
one job and "attached" to another, in a manner which does
destroy any jobs or any network connections
-3-
Hence, it is entirely possible that a user could start up
program that uses sockets n+6 and n+7 (where n is the
Telnet receive socket), detach his terminal from that job,
it to another, attempt to run a program using the
Protocol, and have the attempted data connection fail
sockets n+6 and n+7 are already in use (for the same value of n
since we are referring to the same network terminal).
CONCLUSION 7
There are, of course, a few network-wide socket number
necessary for establishing initial connection
Reserving sockets 0-255 for standard ICP functions is
example of one such convention
Additionally, I think that for the purpose of simplicity it
reasonable to expect any process to be able to gain control
a small block of "adjacent" sockets, such as an even-odd
(as in ICP), if it asks for them at the same time
However, as the foregoing examples have demonstrated, to
further fixed socket number requirements is to risk the danger
making unwarranted assumptions about the nature of
implementations, the structure of user processes, etc.,
individual hosts
Once the initial Telnet connection is established, any
necessary connections should be established by negotiation
the Telnet connection (e.g. by messages of the form "
connect to my socket xxxxxx", "OK, connecting via my
yyyyyy"). There is absolutely no need for any protocol to
fixed socket numbers, except for the purposes of the
connection (ICP).
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
