home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0142.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  4.3 KB  |  113 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                            Charley Kline
  8. Request for Comments #142                        Johnny Wong
  9. NIC #6727                                        UCLA (NMC)
  10. Categories: C.1, C.2, C.3, C.5                   3 May 71
  11. Updates: none
  12. Obsoletes: none
  13.  
  14.  
  15.               Time-out Mechanism in the Host-Host Protocol
  16.  
  17. On sending a message to a foreign site, the following situations can
  18. occur:
  19.  
  20. 1. Destination IMP down - Type 7 message is returned
  21.  
  22. 2. Destination IMP up but destination IMP-HOST interface is
  23.    down - Type 7 message is returned.
  24.  
  25. 3. Destination IMP and IMP-HOST interface up, but IMP-HOST inter-
  26.    face is not taking messages - Type 9 message is returned after
  27.    IMP time-out (ask BBN for time).
  28.  
  29. 4. Destination IMP and IMP-HOST interface up and IMP-HOST inter-
  30.    face is taking messages - Type 5 (rfnm) message is returned.
  31.  
  32. A suggestion for handling type 7 and type 9 messages has been made in
  33. NWG/RFC #117.  In this document we would like to discuss in detail the
  34. problem: what should happen to the HOST-HOST protocol on receiving a
  35. rfnm?
  36.  
  37. When a NCP sends out a STR or RTS control command on a pair of sockets
  38. and gets a rfnm back, this pair of sockets will be in a wait-match
  39. state.  Everything is fine if a matching RTS or STR, or CLS is
  40. returned after a reasonable amount of delay.  Trouble will arise when
  41. nothing is returned after a long time.
  42.  
  43. This can happen if the NCP is not running at all but its host is
  44. taking in messages (e.g. UCLA's host will receive messages even if the
  45. NCP is not running), or if the NCP is running very slowly.  The same
  46. problem exists on sending out a CLS control command and a matching CLS
  47. is never returned.  The trouble is that resources are tied up, e.g.
  48. sockets, links and table space in the NCP; and one would like to
  49. release these resources.  In our implementation, when a user does a
  50. CLOSE, we can't release the sockets until the matching CLS is
  51. returned.  This protects us from getting confused if a seconds request
  52. is made for the same pair of sockets.  This problem can be solved by
  53. including a time-out mechanism in the Host-Host protocol.  This
  54. operates as follows:
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. ne 5
  61. a.  On sending out a STR or RTS and if you do not get back a match-
  62.     ing RTS or STR, or a CLS in T time units a CLS will be sent.
  63.     After sending the time-out CLS race condition can be avoided
  64.     by ignoring the matching RTS or STR that arrives before the
  65.     matching CLS.
  66.  
  67. b.  On sending out a CLS (any kind, including the time-out CLS),
  68.     and if you do not get back a matching CLS in T time units, the
  69.     matching CLS is assumed to have returned.  However, if a RTS or
  70.     STR is sent on the same pair of sockets anytime after the time
  71.     out and before a CLS is returned, and then we receive the CLS,
  72.     there is no way to determine whether this returning CLS is for
  73.     matching the previous CLS or for refusing the RTS or STR.  (See
  74.     the figure for detail).  So far we could not solve this race
  75.     condition except by assigning sequence number to connection
  76.     throughout the Network which we don't think is a good solution
  77.     at all.  Hence, we would like to bring the attention of the
  78.     Host-Host Protocol Glitch Cleaning Committe to this problem.
  79.     The time limit T should be a Network Standard and its value should
  80.     be decided also.
  81.  
  82.        Reason                                Our NCP
  83.        ------                                -------
  84.  
  85.     1. User requests connection              1. RTS ->
  86.  
  87.     2. User gets tired requests CLS
  88.        (or NCP timeout)                      2. CLS ->
  89.  
  90.     3. No matching CLS returned in
  91.        T time units                          3. CLS assumed returned
  92.                                                 free socket and other
  93.                                                 resources
  94.  
  95.     4. User requests another connection
  96.        over same socket pair                 4. RTS ->
  97.  
  98.     5. CLS received                          ?? does it belong to
  99.                                              2 or 4?
  100.  
  101.                                    Figure
  102.  
  103.          [ This RFC was put into machine readable form for entry ]
  104.             [ into the online RFC archives by Gert Doering 4/97]
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.