Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

UNKNOWN
Network Working Group                                   Stephen M. WolfeRequest for Comments: 38                                        UCLA CCN                                                           20 March 1970Comments on Network Protocolfrom 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]

[8]ページ先頭

©2009-2026 Movatter.jp