GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc38

Network Working Group Stephen M. Wolfe Request for Comments: 38 UCLA CCN

                                                         20 March 1970
                    Comments on Network Protocol
                          from NWG/RFC #36
 The proposed protocol does not allow for the possible multiplexing of
 connections over links.
 Generally, this presents no problem, but it might cause loading
 restrictions in the future. Two cases where routing multiple
 connections over the same link are apparent:
       a) Where a user has several high speed connections, such as
          between processes that transmit files over the network.
          Assigning these connections to the same link limits the
          percentage of network resources that may be used by that
          user. This becomes particularly important when several
          store-and-forward IMP's are used by the network to effect
          the communication.
       b) When two hosts each have their own independent network and
          desire to allow access to the other hosts's network over
          the ARPA net, a shortage of links may develop. Again, the
          assignment of several connections to the same link could
          help solve the problem.
 The following changes in the protocol would make possible the future
 use of multiplexed links. It is not necessary to add the
 multiplexing, itself, to the protocol at this time.
       a) The END and RDY must specify relevant sockets in addition to
          the link number. Only the local socket name need be
          supplied.
       b) Problems arise with the RSM and SPD commands. Should they
          refer to an entire link, or just to a given connection?
          Since there is a proposal to modify the RFNM to accommodate
          these commands, it might be better to add another set of
          commands to block and unblock a connection, but I am not
          convinced that that is the best solution.
       c) The destintation socket must be added to the header of each
          message on the data link. Presumably this would consist of
          32 bits immediately after the header and before the marking.
     [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Karl Reinsch 1/97 ]
                                                              [Page 1]
/data/webs/external/dokuwiki/data/pages/rfc/rfc38.txt · Last modified: 1997/03/13 15:48 (external edit)