home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0151.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  3.5 KB  |  116 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. NWG/RFC # 151                                                 A. Shoshani
  8.                                                               SDC
  9. NIC #6755                                                     May 10, 1971
  10.  
  11.  
  12.  
  13.  
  14.                    COMMENTS ON A PROFERRED OFFICIAL ICP
  15.                              (RFCs 123, 127)
  16.  
  17.  
  18.  
  19.  
  20.  
  21. Bob Long at SDC noticed that the order in which messages go out to the
  22. network depend on the local NCP. In particular commands may be given
  23. priority over data and therefore in the sequence specified for server in
  24. RFC 123 (top of Page 3), the last two INIT commands may go out before the
  25. data = S on socket = L is sent.  (This is the case in the current
  26. implementation of SDC's NCP.) The implication is that the user's NCP should
  27. be prepared to keep the INIT's it received from the server until the user
  28. process gets the data = S and issues two INITs in response.
  29.  
  30. This case is brought up now so that people will think about it before the
  31. Atlantic City meeting and comment whether their NCP can tolerate it. It may
  32. be necessary to make it explicit in the ICP that the two INITs sent by the
  33. server should go out only after the data = S is sent, or even after the
  34. user process acknowledges its receipt.
  35.  
  36. I have a more general remark about the ICP. This is a third level protocol
  37. and therefore should not alter or ignore procedures of the second level
  38. protocol (Host-Host protocol). In particular three remarks seem
  39. appropriate:
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Kreznar                                                         [Page 1]
  59.  
  60. RFC 19                                                      October 1969
  61.  
  62.  
  63. 1. In RFC 123 (bottom of Page 2) it is suggested that the byte size for the
  64.    connection to the server socket L is 32. However, in the modifications
  65.    to second level protocol (RDC 107) it is specified that it is up to the
  66.    sending process to chose the byte size. According to the Host-Host
  67.    protocol, NCPs should be prepared to accept messages in any byte size
  68.    (1<= size <=255);  therefore there is no need to impose a size of 32 in
  69.    this case.  Furthermore, since it is up to the sender to choose the byte
  70.    size, some Hosts may choose a particular byte size (for simplicity and
  71.    convenience) and their NCP may not be geared to transmit in an imposed
  72.    byte size.
  73.  
  74. 2. In RFCs 66 and 80, an ALL is expected on the connection to the server
  75.    socket before data can be sent. In RFCs 123 and 127 the ALL requirement
  76.    disappeared.  But the ALL is a Host-Host protocol requirement and not
  77.    requiring it creates special case. A particular NCP implementation may
  78.    cause the ALL to be sent internally when a connection is created,
  79.    without the user process having control of it. Relaxing this requirement
  80.    will create a special case for the receiving NCP not to send the ALL and
  81.    for the sending NCP to send the data = S without first receiving an ALL.
  82.  
  83. 3. In RFC 127, I disagree with the comment "send 32 bits of data in one
  84.    message" because it is a second level protocol decision that a message
  85.    can be sent in any size pieces and the size is to be specified through
  86.    the ALL mechanism. In particular, there may be hosts which are not
  87.    prepared to accept more than few bytes at a time (TIPs).
  88.  
  89. In general we should not make second level decisions in a third level
  90. protocol.
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.         [ This RFC was put into machine readable form for entry ]
  98.         [ into the online RFC archives by BBN Corp. under the   ]
  99.         [ direction of Alex McKenzie.                   12/96   ]
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Kreznar                                                         [Page 2]
  115.  
  116.