home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 200s / rfc202.txt next >
Text File  |  1997-06-26  |  3KB  |  113 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        Steve Wolfe
  8. Request for Comments:  #202                                     UCLA-CCN
  9. NIC #7155                                                     Jon Postel
  10. Categories:  D                                                  UCLA-NMC
  11. References:  Document #2                                    26 July 1971
  12. Obsoletes:  None
  13.  
  14. We have noticed a possible deadlock situation which may arise using the
  15. Initial Connection Protocol (ICP) specified in Document #2 (NIC #7101 in
  16. the Current Network Protocols Notebook NIC #7104).
  17.  
  18. If on both sides one RFC is issued and a "wait for match" is required
  19. before the second RFC is issued, it is possible that the first RFC's
  20. will not match.  In particular a deadlock will occur if both sides open
  21. their send or both sides open their receive sockets first.
  22.  
  23. Briefly the ICP is:
  24. <where the original uses a script lowercase letter with a single digit
  25. subscript we use the lower case letter followed by {digit} so that
  26. script-m-subscript-2 is printed m{2}>
  27.  
  28. Server                                User
  29. ------                                ----
  30.  
  31. S1:  Listen on socket L.              U1:  RTS(U, L, l{1})
  32.  
  33. S2:  Wait for a match.                U2:  Wait for match.
  34.  
  35. S3:  STR(L, U, s{1})
  36.  
  37. S4:  Wait for allocation.             U3:  All(l{1}, m{1}, b{1})
  38.  
  39. S5:  Send data S in s{1} bit          U4:  Receive data S in s{1}
  40.      bytes as allowed by                   bit bytes.
  41.      allocation m{1}, b{1}.
  42.  
  43. S6:  CLS(L, U)                        U5:  CLS(U, L)
  44.  
  45. S7:  RTS(S, U+3, l{2})                U6:  STR(U+3, S, s{2})
  46.  
  47. S8:  STR(S+1, U+2, s{3})              U7:  RTS(U+2, S+1, l{3})
  48.  
  49. "The labels here imply no ordering except that ordering required by the
  50. Host-Host Protocol.  Note that steps S7 and S8 can be reversed as can U6
  51. and U7.  Also, notice that at any time after S2 the server could
  52. initiate steps S7 and S8 in parallel with steps S3 through S6, and that
  53. at any time after U4 the user could initiate steps U6 and U7 in parallel
  54. with step U5."
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. We recommend that the server perform steps 7 and 8 before waiting for
  61. the user to perform step 6 or 7.  It is also suggested that the user
  62. issue the RFC's in steps 6 and 7 without waiting for the server.  (If
  63. the user is only Listening then both Listens should be issued without
  64. waiting for the server.)  If for some reason a host must delay between
  65. issuing RFC's it must issue the RFC's involving sockets S and U+3 first.
  66.  
  67.        [ This RFC was put into machine readable form for entry ]
  68.          [ into the online RFC archives by Robert Barnes 6/97 ]
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.