home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 100s / rfc147.txt < prev    next >
Text File  |  1997-03-12  |  6KB  |  166 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                         Network Working Group
  8.  
  9.  
  10.                         Request for Comment 147
  11.  
  12.                                 NIC 6750
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.                         The Definition of a Socket
  23.  
  24.                              Joel M. Winett
  25.  
  26.                             Lincoln Laboratory
  27.  
  28.                                    360/67
  29.  
  30.                                 7 May 1971
  31.  
  32.  
  33. Category: C1, C3, D1, H
  34. RFC obsoleted: None
  35. RFC updated: None
  36. Related RFCs: RFC-129 (NIC-5845)
  37.  
  38.  
  39.  
  40.  
  41.  
  42.    This material has not been reviewed for public release and is intended
  43.    only for use with the ARPA network. It should not be quoted or cited
  44.    in any publication not related to the ARPA network.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60.                  MASSACHUSETTS INSTITUTE OF TECHNOLOGY
  61.                            LINCOLN LABORATORY
  62.  
  63. TO:      Network Socket Committee and Network Community        7 May 1971
  64.  
  65. FROM:    J. M. Winett (LL)
  66.  
  67. SUBJECT: The Definition of a Socket
  68.  
  69. A socket is defined to be the unique identification to or from which
  70. information is transmitted in the network. The socket is specified as a 32
  71. bit number with even sockets identifying receiving sockets and odd sockets
  72. identifying sending sockets. A socket is also identified by the host in
  73. which the sending or receiving processer is located.
  74.  
  75. Previous network papers postulated that a process running under control of
  76. the host's operating system would have access to a number of ports. A port
  77. might be a physical input or output device, or a logical I/O device
  78. supported by system calls to the host's operating system.  The latter
  79. category includes a) I/O directed to a physical device which is being
  80. spooled by the operating system, b) a physical device whose basic
  81. characteristics have not been altered but whose access has been limited and
  82. possibly transformed by a mapping algorithm (e.g. device address mapping or
  83. cylinder relocation as in virtual mini disks), c) access to a file system
  84. through a directory and access method maintained by the operating system,
  85. d) a procedure for process to process communications, e) a procedure for
  86. machine to machine communication (such as defined by the network protocol.)
  87.  
  88. A socket has been defined to be the identification of a port for machine to
  89. machine communication through the ARPA network. Sockets allocated to each
  90. host must be uniquely associated with a known process or be undefined. The
  91. name of some sockets must be universally known and associated with a known
  92. process operating with a specified protocol. (e.g., a logger socket, RJE
  93. socket, a file transfer socket). The name of other sockets might not be
  94. universally known, but given in a transmission over a universally known
  95. socket, (c. g. the socket pair specified by the transmission over the
  96. logger socket under the Initial Connection Protocol (ICP). In any case,
  97. communication over the network is from one socket to another socket, each
  98. socket being identified with a process running at a known host.
  99.  
  100. The question arises as to whether socket names must be known to users of
  101. network programs or whether the specification of sockets can be made
  102. transparent to the user. Also, should the socket used at one time by a
  103. process be the same socket used at a later time by the same process for the
  104. same purpose? If sockets are not transparent to the user, then the sockets
  105. used must not be dependent on the order in which network connections are
  106. made.
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113. Network Socket Committee and Network Community        7 May 1971
  114.  
  115. The definition of a socket is also related to the accounting procedures
  116. followed for network usage.  Network Control Programs (NCPs) should log
  117. each connection made and record the time the connection was made, the time
  118. the connection was closed, the number of messages and number of bits
  119. transmitted over the connection, the sending and receiving hosts, and the
  120. sockets at the sending host and receiving host which participated in the
  121. connection. In order for these sockets to be meaningful, they should be
  122. identifiable with the user, account, or process name with which each socket
  123. is associated.
  124.  
  125. It has previously been suggested that the sockets used by a network user be
  126. identified with that user no matter which host he used for network
  127. communications. Users would be registered at some host and be identified as
  128. a user from that host even if he used the system as a second host to
  129. communicate with the system at a third host.
  130.  
  131. To satisfy the above requirements within the name space of a 32 bit socket,
  132. the following procedure is suggested. This procedure has been implemented
  133. with the NCP on the Lincoln Laboratory 360/67 system and is used by all
  134. processes making use of network facilities. ) A 32 bit socket is divided
  135. into an 8 bit "home" field, a 16 bit "user" field and an 8 bit "tag" field.
  136. The tag consists of a 7 bit "plug" and a one bit "polarity" where a "0"
  137. polarity indicates a receive socket and a "1" polarity indicates a send
  138. socket. Thus a user on one host system may run processes with up to 128
  139. send sockets and 128 receive sockets.  This procedure allows for 256 hosts
  140. and 65,536 users per host.  The only difficulty is in mapping user or
  141. process identifiers at a host into a 16 bit user number. This may be done
  142. through a table lookup, possibly using a hash coding technique.  Though
  143. many systems have a unique run time index associated with each process, if
  144. this index were used as the user number, the user number would not be the
  145. same each time the process were used for network activity.  What is
  146. required, is a unique mapping from a process identifier (usually a
  147. character string) into a 16 bit binary number.
  148.  
  149. The sockets used for facilities following a common network protocol, such
  150. as the ICP, should also follow this socket definition. Thus the logger
  151. socket at the Lincoln Laboratory 360/67 would be, and is, x'0A0000 01, ',
  152. i.e. home 10, user 0, and tag 1.
  153.  
  154. This procedure for defining sockets enables an accounting procedure for
  155. identifying users of network facilities and for measuring network usage.
  156.  
  157.        [ This RFC was put into machine readable form for entry ]
  158.        [ into the online RFC archives by BBN Corp. under the   ]
  159.        [ direction of Alex McKenzie.                   12/96   ]
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166.