RFC202 日本語訳
0202 Possible Deadlock in ICP. S.M. Wolfe, J. Postel. July 1971. (Format: TXT=2796 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Steve Wolfe Request for Comments: #202 UCLA-CCN NIC #7155 Jon Postel Categories: D UCLA-NMC References: Document #2 26 July 1971 Obsoletes: None
コメントを求めるワーキンググループスティーブウルフRequestをネットワークでつないでください: #202 UCLA-CCN NIC#7155ジョンポステルCategories: D UCLA-NMC参照: ドキュメント#2 1971年7月26日は以下を時代遅れにします。 なし
We have noticed a possible deadlock situation which may arise using the Initial Connection Protocol (ICP) specified in Document #2 (NIC #7101 in the Current Network Protocols Notebook NIC #7104).
私たちはDocument#2(Current NetworkプロトコルNotebook NIC#7104のNIC#7101)で指定されたInitial Connectionプロトコル(ICP)を使用することで起こるかもしれない可能な行き詰まり状況に気付きました。
If on both sides one RFC is issued and a "wait for match" is required before the second RFC is issued, it is possible that the first RFC's will not match. In particular a deadlock will occur if both sides open their send or both sides open their receive sockets first.
両側では、1RFCが発行されて、第2RFCが発行される前に「マッチのための待ち」が必要であるなら、RFCの最初のものが合っていないのは、可能です。 両側が開くと特に、行き詰まりが起こる、それら、発信してください。さもないと、両側が開く、それら、最初に、ソケットを受けてください。
Briefly the ICP is: <where the original uses a script lowercase letter with a single digit subscript we use the lower case letter followed by {digit} so that script-m-subscript-2 is printed m{2}>
簡潔に、ICPは以下の通りです。 オリジナルが私たちが、より低く使用する一桁の添字があるスクリプト小文字を使用する<がケタがあとに続いた手紙をケースに入れるので、スクリプトm添字2は印刷されたmです。2 >。
Server User ------ ----
サーバーのユーザ------ ----
S1: Listen on socket L. U1: RTS(U, L, l{1})
S1: ソケットL. U1で聴いてください: RTS(U、L、l1)
S2: Wait for a match. U2: Wait for match.
S2: マッチを待ってください。 U2: マッチを待ってください。
S3: STR(L, U, s{1})
S3: STR(L、U、s1)
S4: Wait for allocation. U3: All(l{1}, m{1}, b{1})
S4: 配分を待ってください。 U3: すべて(l1、m1、b1)
S5: Send data S in s{1} bit U4: Receive data S in s{1} bytes as allowed by bit bytes. allocation m{1}, b{1}.
S5: sの1ビットのU4でデータSを送ってください: 噛み付いているバイト配分m1、b1時までに許容されているようにsにデータSを1バイト受け取ってください。
S6: CLS(L, U) U5: CLS(U, L)
S6: CLS(L、U)U5: CLS(U、L)
S7: RTS(S, U+3, l{2}) U6: STR(U+3, S, s{2})
S7: RTS(S、U+3、l2)U6: STR(U+3、S、s2)
S8: STR(S+1, U+2, s{3}) U7: RTS(U+2, S+1, l{3})
S8: STR(S+1、U+2、s3)U7: RTS(U+2、S+1、l3)
"The labels here imply no ordering except that ordering required by the Host-Host Protocol. Note that steps S7 and S8 can be reversed as can U6 and U7. Also, notice that at any time after S2 the server could initiate steps S7 and S8 in parallel with steps S3 through S6, and that at any time after U4 the user could initiate steps U6 and U7 in parallel with step U5."
「注文がHost-ホストプロトコルが必要である以外に、ここのラベルは注文を含意しません。」 U6とU7であることができることのようにステップのS7とS8を逆にすることができることに注意してください。 「また、S2の後にいつでも、サーバがステップのS3からS6と平行してステップのS7とS8を開始するかもしれなくて、U4の後にいつでも、ユーザがステップU5と平行してステップのU6とU7を開始できたのに注意してください。」
[Page 1] We recommend that the server perform steps 7 and 8 before waiting for the user to perform step 6 or 7. It is also suggested that the user issue the RFC's in steps 6 and 7 without waiting for the server. (If the user is only Listening then both Listens should be issued without waiting for the server.) If for some reason a host must delay between issuing RFC's it must issue the RFC's involving sockets S and U+3 first.
[1ページ] 私たちは、サーバがユーザがステップ6か7を実行するのを待つ前にステップ7と8を実行することを勧めます。 また、ユーザがステップ6と7でサーバを待たないでRFCのものを発行することが提案されます。. (ユーザがListeningにすぎないなら、サーバを待たないで、両方のListensは発行されるべきです。) RFCを発行するときある理由でホストが延着しなければならないなら、それは、RFCが最初にソケットSとU+3にかかわるのを発行しなければなりません。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Robert Barnes 6/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロバート・バーンズ6/97によるオンラインRFCアーカイブへの]
[Page 2]
[2ページ]
一覧
スポンサーリンク