RFC675 日本語訳
0675 Specification of Internet Transmission Control Program. V. Cerf,Y. Dalal, C. Sunshine. December 1974. (Format: TXT=156874 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Vinton Cerf Request for Comments: 675 Yogen Dalal NIC: 2 Carl Sunshine INWG: 72 December 1974
SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM
December 1974 Version
1. INTRODUCTION
This document describes the functions to be performed by the internetwork Transmission Control Program [TCP] and its interface to programs or users that require its services. Several basic assumptions are made about process to process communication and these are listed here without further justification. The interested reader is referred to [CEKA74, TOML74, BELS74, DALA74, SUNS74] for further discussion.
The authors would like to acknowledge the contributions of R. Tomlinson (three way handshake and Initial Sequence Number Selection), D. Belsnes, J. Burchfiel, M. Galland, R. Kahn, D. Lloyd, W. Plummer, and J. Postel all of whose good ideas and counsel have had a beneficial effect (we hope) on this protocol design. In the early phases of the design work, R. Metcalfe, A. McKenzie, H. Zimmerman, G. LeLann, and M. Elie were most helpful in explicating the various issues to be resolved. Of course, we remain responsible for the remaining errors and misstatements which no doubt lurk in the nooks and crannies of the text.
Processes are viewed as the active elements of all HOST computers in a network. Even terminals and files or other I/O media are viewed as communicating through the use of processes. Thus, all network communication is viewed as inter-process communication.
Since a process may need to distinguish among several communication streams between itself and another process [or processes], we imagine that each process may have a number of PORTs through which it communicates with the ports of other processes.
Since port names are selected independently by each operating system, TCP, or user, they may not be unique. To provide for unique names at each TCP, we concatenate a NETWORK identifier, and a TCP identifier with a port name to create a SOCKET name which will be unique throughout all networks connected together.
Cerf, Dalal & Sunshine [Page 1] RFC 675 Specification of Internet TCP December 1974
A pair of sockets form a CONNECTION which can be used to carry data in either direction [i.e. full duplex]. The connection is uniquely identified by the <local socket, foreign socket> address pair, and the same local socket can participate in multiple connections to different foreign sockets [see Section 2.2].
Processes exchange finite length LETTERS as a way of communicating; thus, letter boundaries are significant. However, the length of a letter may be such that it must be broken into FRAGMENTS before it can be transmitted to its destination. We assume that the fragments will normally be reassembled into a letter before being passed to the receiving process. Throughout this document, it is legitimate to assume that a fragment contains all or a part of a letter, but that a fragment never contains parts of more than one letter.
We specifically assume that fragments are transmitted from Host to Host through means of a PACKET SWITCHING NETWORK [PSN] [ROWE70, POUZ73]. This assumption is probably unnecessary, since a circuit switched network could also be used, but for concreteness, we explicitly assume that the hosts are connected to one or more PACKET SWITCHES [PS] of a PSN [HEKA7O, POUZ74, SCWI71].
Processes make use of the TCP by handing it letters. The TCP breaks these into fragments, if necessary, and then embeds each fragment in an INTERNETWORK PACKET. Each internetwork packet is in turn embedded in a LOCAL PACKET suitable for transmission from the host to one of its serving PS. The packet switches may perform further formatting or other operations to achieve the delivery of the local packet to the destination Host.
The term LOCAL PACKET is used generically here to mean the formatted bit string exchanged between a host and a packet switch. The format of bit strings exchanged between the packet switches in a PSN will generally not be of concern to us. If an internetwork packet is destined for a TCP in a foreign PSN, the packet is routed to a GATEWAY which connects the origin PSN with an intermediate or the destination PSN. Routing of internetwork packets to the GATEWAY may be the responsibility of the source TCP or the local PSN, depending upon the PSN Implementation.
One model of TCP operation is to imagine that there is a basic GATEWAY associated with each TCP which provides an interface to the local network. This basic GATEWAY performs routing and packet reformatting or embedding, and may also implement congestion and error control between the TCP and GATEWAYS at or intermediate to the destination TCP.
Cerf, Dalal & Sunshine [Page 2] RFC 675 Specification of Internet TCP December 1974
At a GATEWAY between networks, the internetwork packet is unwrapped from its local packet format and examined to determine through which network the internetwork packet should travel next. The internetwork packet is then wrapped in a local packet format suitable to the next network and passed on to a new packet switch.
A GATEWAY is permitted to break up the fragment carried by an internetwork packet into smaller fragments if this is necessary for transmission through the next network. To do this, the GATEWAY produces a set of internetwork packets, each carrying a new fragment. The packet format is designed so that the destination TCP may treat fragments created by the source TCP or by intermediate GATEWAYS nearly identically.
The TCP is responsible for regulating the flow of internetwork packets to and from the processes it serves, as a way of preventing its host from becoming saturated or overloaded with traffic. The TCP is also responsible for retransmitting unacknowledged packets, and for detecting duplicates. A consequence of this error detection/retransmission scheme is that the order of letters received on a given connection is also maintained [CEKA74, SUNS74]. To perform these functions, the TCP opens and closes connections between ports as described in Section 4.3. The TCP performs retransmission, duplicate detection, sequencing, and flow control on all communication among the processes it serves.
2. The TCP INTERFACE to the USER
2.1 The TCP as a POST OFFICE
The TCP acts in many ways like a postal service since it provides a way for processes to exchange letters with each other. It sometimes happens that a process may offer some service, but not know in advance what its correspondents' addresses are. The analogy can be drawn with a mail order house which opens a post office box which can accept mail from any source. Unlike the post box, however, once a letter from a particular correspondent arrives, a port becomes specific to the correspondent until the owner of the port declares otherwise.
In addition to acting like a postal service, the TCP insures end-to- end acknowledgment, error correction, duplicate detection, sequencing, and flow control.
Cerf, Dalal & Sunshine [Page 3] RFC 675 Specification of Internet TCP December 1974
2.2 Sockets and Addressing
We have borrowed the term SOCKET from the ARPANET terminology [CACR70, MCKE73]. In general, a socket is the concatenation of a NETWORK identifier, TCP identifier, and PORT identifier. A CONNECTION is fully specified by the pair of SOCKETS at each end since the same local socket may participate in many connections to different foreign sockets.
Once the connections is specified in the OPEN command [see section 2.3.2], the TCP supplies a [short] Local Connection Name by which the user refers to the connection in subsequent commands. In particular this facilitates using connections with initially unspecified foreign sockets.
TCP's are free to associate ports with processes however they choose. However, several basic concepts seem necessary in an implementation. There must be well known sockets [WKS] which the TCP associates only with the "appropriate" processes by some means. We envision that processes may "own" sockets, and that processes can only initiate connections on the sockets they own [means for implementing ownership is a local issue, but we envision a Request Port user call, or a method of uniquely allocating a group of ports to a given process, e.g. by associating the high order bits of a port name with a given process.]
Once initiated, a connection may be passed to another process that does not own the local socket [e.g. from logger to service process]. Strictly speaking this is a reconnection issue which might be more elegantly handled by a general reconnection protocol as discussed in section 3.3. To simplify passing a connection within a single TCP, such "invisible" switches may be allowed as in TENEX systems.
Of course, each connection is associated with exactly one process, and any attempt to reference that connection by another process will be signaled as an error by the TCP. This prevents stealing data from or inserting data into another process' data stream.
A connection is initiated by the rendezvous of an arriving internetwork packet and a waiting Transmission Control Block [TCB] created by a user OPEN, SEND, INTERPUPT, or RECEIVE call [see section 2.3]. The matching of local and foreign socket identifiers determines when a successful connection has been initiated. The connection becomes established when sequence numbers have been synchronized in both directions as described in section 4.3.2.
Cerf, Dalal & Sunshine [Page 4] RFC 675 Specification of Internet TCP December 1974
It is possible to specify a socket only partially by setting the PORT identifier to zero or setting both the TCP and PORT identifiers to zero. A socket of all zero is called UNSPECIFIED. The purpose behind unspecified sockets is to provide a sort of "general delivery" facility [useful for logger type processes with well known sockets].
There are bounds on the degree of unspecificity of socket identifiers. TCB's must have fully specified local sockets, although the foreign socket may be fully or partly unspecified. Arriving packets must have fully specified sockets.
We employ the following notation:
x.y.z = fully specified socket with x=net, y=TCP, z=port
x.y.u = as above, but unspecified port
x.u.u = as above, but unspecified TCP and port
u.u.u = completely unspecified
with respect to implementation, u = 0 [zero]
We illustrate the principles of matching by giving all cases of
incoming packets which match with existing TCB's. Generally, both
the local (foreign) socket of the TCB and the foreign (local) socket
of the packet must match.
TCB local TCB foreign Packet local Packet foreign
(a) a.b.c e.f.g e.f.g a.b.c
(b) a.b.c e.f.u e.f.g a.b.c
(c) a.b.c e.u.u e.f.g a.b.c
(d) a.b.c u.u.u e.f.g a.b.c
There are no other legal combinations of socket identifiers which
match. Case (d) is typical of the ARPANET well known socket idea in
which the well known socket (a.b.c) LISTENS for a connection from
any (u.u.u) socket. Cases (b) and (c) can be used to restrict
matching to a particular TCP or net.
Cerf, Dalal & Sunshine [Page 5] RFC 675 Specification of Internet TCP December 1974
2.3 TCP USER CALLS
2.3.1 A Note on Style
The following sections functionally define the USER/TCP interface.
The notation used is similar to most procedure or function calls in
high level languages, but this usage is not meant to rule out trap
type service calls [e.g. SVC's, UUO's, EMT's,...].
The user calls described below specify the basic functions the TCP
will perform to support interprocess communication. Individual
implementations should define their own exact format, and may
provide combinations or subsets of the basic functions in single
calls. In particular, some implementations may wish to automatically
OPEN a connection on the first SEND, RECEIVE, or INTERRUPT issued by
the user for a given connection.
In providing interprocess communication facilities, the TCP must not
only accept commands, but also return information to the processes
it serves. This communication consists of:
(a) general information about a connection [interrupts, remote
close, binding of unspecified foreign socket].
(b) replies to specific user commands indicating success or various
types of failure.
Although the means for signaling user processes and the exact format of replies will vary from one implementation to another, it would promote common understanding and testing if a common set of codes were adopted. Such a set of Event Codes is described in section 2.4.
With respect to error messages, references to "local" and "foreign" are ambiguous unless it is known whether these refer to the world as seen by the sender or receiver of the error message. The authors attempted several different approaches and finally settled on the convention that these references would be as seen by the receiver of the message.
2.3.2 OPEN CONNECTION
Format: OPEN(local port, foreign socket [, timeout])
We assume that the local TCP is aware of the identity of the processes it serves and will check the authority of the process to use the connection specified. Depending upon the implementation of the TCP, the source network and TCP identifiers will either be supplied by the TCP or by the processes that serve it [e.g. the
Cerf, Dalal & Sunshine [Page 6] RFC 675 Specification of Internet TCP December 1974
program which interfaces the TCP to its packet switch or the packet switch itself]. These considerations are the result of concern about security, to the extent that no TCP be able to masquerade as another one, and so on. Similarly, no process can masquerade as another without the collusion of the TCP.
パケット交換機かパケット交換機自体にTCPを接続するプログラム] これらの問題はセキュリティに関して重要な結果です、どんなTCPも別の1などのふりをすることができないという範囲に。 同様に、どんなプロセスもTCPの共謀なしで別のもののふりをすることができません。
If no foreign socket is specified [i.e. the foreign socket parameter is 0 or not present], then this constitutes a LISTENING local socket which can accept communication from any foreign socket. Provision is also made for partial specification of foreign sockets as described in section 2.2.
どんな外国ソケットも指定されないなら[すなわち、外国ソケットパラメタはプレゼントではなく、0です]、これはどんな外国ソケットからもコミュニケーションを受け入れることができるLISTENINGの地方のソケットを構成します。 また、セクション2.2で説明されるように外国ソケットの部分的な仕様に備えます。
If the specified connection is already OPEN, an error is returned, otherwise a full-duplex transmission control block [TCB] is created and partially filled in with data from the OPEN command parameters. The TCB format is described in more detail in section 4.2.2.
オープン、誤りが指定された接続が既にそうなら返されて、さもなければ、全二重伝送制御ブロック[TCB]は、作成されて、オープンコマンドパラメタからのデータで部分的に記入されます。 TCB形式はさらに詳細にセクション4.2.2で説明されます。
No network traffic is generated by the OPEN command. The first SEND or INTERRUPT by the local user or the foreign user will cause the TCP to synchronize the connection.
ネットワークトラフィックは全くオープン命令で生成されません。 地元のユーザか外国人のユーザによる最初のSENDかINTERRUPTがTCPに接続を同時にさせるでしょう。
The timeout, if present, permits the caller to set up a timeout for all letters transmitted on the connection. If a letter is not successfully transmitted within the timeout period, the user is notified and may ignore the condition [TCP will continue trying to transmit] or direct the TCP to close the connection. The present global default is 30 seconds, and connections which are set up without specifying another timeout will retransmit every letter for at least 30 seconds before notifying the user. The retransmission rate may vary, and is the responsibility of the TCP and not the user. Most likely, it will be related to the measured time for responses to return from letters sent.
存在しているなら、タイムアウトは、訪問者が接続のときに伝えられたすべての手紙のためにタイムアウトをセットアップすることを許可します。 手紙がタイムアウト時間中に首尾よく伝えられないなら、ユーザは、通知されて、条件[TCPは、伝わろうとし続ける]を無視するか、または接続を終えるようTCPに指示するかもしれません。 現在のグローバルなデフォルトは30秒です、そして、ユーザに通知する前に、別のタイムアウトを指定しないでセットアップされる接続は少なくとも30秒間、あらゆる手紙を再送するでしょう。 「再-トランスミッション」レートは、異なるかもしれなくて、ユーザではなく、TCPの責任です。 たぶん、応答が送られた手紙から戻る測定時間に関連するでしょう。
Depending on the TCP implementation, either a local connection name will be returned to the user by the TCP, or the user will specify this local connection name (in which case another parameter is needed in the call). The local connection name can then be used as a short hand term for the connection defined by the <local socket, foreign socket> pair.
TCP実装によって、市内接続名がTCPによってユーザに返されるだろうか、またはユーザはこの市内接続名を指定するでしょう(その場合、別のパラメタが呼び出しで必要です)。 そして、<の地方のソケット(外国人のソケット>組)によって定義された接続に短い手の期間として市内接続名を使用できます。
Responses from the TCP which may occur as a result of this call are detailed in section 2.4.
この呼び出しの結果、起こるかもしれないTCPからの応答はセクション2.4で詳細です。
2.3.3 SEND LETTER
2.3.3 手紙を送ってください。
Format: SEND(local connection name, buffer address, byte count, EOL flag [, timeout])
形式: 発信してください。(市内接続名、バッファアドレス、EOLが旗を揚げさせるバイト・カウント[タイムアウト])
Cerf, Dalal & Sunshine [Page 7] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[7ページ]RFC675仕様
This call causes the data contained in the indicated user buffer to be sent on the indicated connection. If the connection has not been opened, the SEND is considered an error. Some implementations may allow users to SEND first, in which case an automatic OPEN would be done. If the calling process is not authorized to use this connection, an error is returned.
この呼び出しで、示されたユーザバッファに含まれたデータを示された接続に送ります。 接続が開かれていないなら、SENDは誤りであると考えられます。 いくつかの実装が最初にSENDにユーザを許容するかもしれません、その場合、自動オープンをするでしょう。 呼び出しプロセスがこの接続を使用するのが認可されないなら、誤りは返されます。
If the EOL flag is set, the data is the End Of a Letter, and the EOL bit will be set in the last packet created from the buffer. If the EOL f1ag is not set, subsequent SEND's will appear as part of the same letter. This extended letter facility should be used sparingly because some TCP's may delay processing packets until an entire letter is received.
EOL旗が設定されるなら、データは、End OfのLetterと、最終におけるセットがバッファから作成されたパケットであるつもりであったなら噛み付かれたEOLです。 EOL f1agが用意ができていないと、その後のSENDのものは同じ手紙の一部として現れるでしょう。 TCPの何らかのものが、全体の手紙が受け取られているまでパケットを処理するのを遅らせるかもしれないので、この拡張手紙施設は控えめに使用されるべきです。
If no foreign socket was specified in the OPEN, but the connection is established [e.g. because a listening connection has become specific due to a foreign letter arriving for the local port] then the designated letter is sent to the implied foreign socket. In general, users who make use of OPEN with an unspecified foreign socket can make use of SEND without ever explicitly knowing the foreign socket address.
オープンでどんな外国ソケットも指定しませんでしたが、接続を確立するなら[例えば、聴取接続が地方のポートに到着する外国手紙のために特定になったので]、暗示している外国ソケットに指定された手紙を送ります。 一般に、明らかに外国ソケットアドレスを知らないで、不特定の外国ソケットによるオープンを利用するユーザはSENDを利用できます。
However, if a SEND is attempted before the foreign socket becomes specified, an error will be returned. Users can use the STATUS call to determine the status of the connection. In some implementations the TCP may notify the user when an unspecified socket is bound.
しかしながら、外国ソケットが指定されるようになる前にSENDが試みられると、誤りは返されるでしょう。 ユーザは接続の状態を決定するというSTATUS要求を使用できます。 いくつかの実装では、不特定のソケットが制限されているとき、TCPはユーザに通知するかもしれません。
If the timeout is specified, then the current default timeout for this connection is changed to the new one. This can affect not only all letters sent including and after this one, but also those which have not yet been sent, since the timeout is kept in the TCB and not associated with each letter sent. Of course, a time is maintained for each internetwork packet formed so as to determine how long each of these has been on the retransmission queue.
タイムアウトが指定されるなら、この接続のための現在のデフォルトタイムアウトは新しい方に変わります。 これは含めさせてこの後のすべての手紙だけではなく、まだ送られないものにも影響できます、タイムアウトがTCBに保たれて、送る各手紙に関連づけられないので。 もちろん、時間はそれぞれのこれらが再送キューのときにどれくらい長いかを決定するために形成されたそれぞれのインターネットワークパケットのために維持されます。
In the simplest implementation, SEND would not return control to the sending process until either the transmission was complete or the timeout had been exceeded. This simple method is highly subject to deadlocks and is not recommended. [For example both sides of the connection try to do SEND's before doing any RECEIVE's.] A more sophisticated implementation would return immediately to allow the process to run concurrently with network I/O, and, furthermore, to allow multiple SENDs to be in progress concurrently. Multiple SENDs are served in first come, first served order, so the TCP will queue those it cannot service immediately.
最も簡単な実装では、トランスミッションが終了していたか、またはタイムアウトが超えられるまで、SENDは送付プロセスにコントロールを返さないでしょう。 この簡単なメソッドは、行き詰まりを非常に受けることがあって、推薦されません。 [どんなRECEIVEもする前に、例えば、接続の両側はSENDのものをしようとします。] より洗練された実装はすぐに、戻って、プロセスが、そして、その上、同時にネットワーク入出力と共に稼働して、複数のSENDsが同時に進行しているのを許容するのを許容するでしょう。 複数のSENDsが先着順のオーダーで役立たれているので、TCPはそれがすぐに修理できないものを列に並ばせるでしょう。
Cerf, Dalal & Sunshine [Page 8] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[8ページ]RFC675仕様
NOTA BENE: In order for the process to distinguish among error or success indications for different letters, the buffer address should be returned along with the coded response to the SEND request. We will offer an example event code format in section 2.4, showing the information which should be returned to the calling process.
背板嘆願: 異なった手紙のための誤りか成功指摘の中で区別するプロセスにおいて整然とします、SEND要求へのコード化された応答と共にバッファアドレスを返すべきです。 私たちはセクション2.4で例のイベントコード形式を提供するつもりです、どれが呼び出しプロセスに返されるべきであるかを情報に示して。
The semantics of the INTERRUPT call are described later, but this call can have an effect on letters which have been given to the TCP but not yet sent. In particular, all such letters are flushed by the source TCP. Thus one of the responses to a SEND may be "flushed due to interrupt."
INTERRUPT呼び出しの意味論は後で説明されますが、この呼び出しはTCPに与えますが、まだ送らない手紙に影響を与えることができます。 特に、そのようなすべての手紙がソースTCPによって洗い流されます。 したがって、SENDへの応答の1つは「中断のため洗い流されるかもしれません」。
Responses from the TCP which may occur as a result of this call are detailed in section 2.4.
この呼び出しの結果、起こるかもしれないTCPからの応答はセクション2.4で詳細です。
2.3.4 RECEIVE LETTER
2.3.4 手紙を受け取ってください。
Format: RECEIVE(local connection name, buffer address, byte count)
形式: 受信してください。(市内接続名、バッファアドレス、バイト・カウント)
This command allocates a receiving buffer associated with the specified connection. If no OPEN precedes this command or the calling process is not authorized to use this connection, an error is returned.
このコマンドは指定された接続に関連している受信バッファを割り当てます。 どんなオープンもこのコマンドに先行しないか、または呼び出しプロセスがこの接続を使用するのが認可されないなら、誤りは返されます。
In the simplest implementation, control would not return to the calling program until either a letter was received, or some error occurred, but this scheme is highly subject to deadlocks [see section 2.3.3]. A more sophisticated implementation would permit several RECEIVE's to be outstanding at once, These would be filled as letters arrive. This strategy permits increased throughput, at the cost of a more elaborate scheme [possibly asynchronous] to notify the calling program that a letter has been received.
最も簡単な実装では、手紙を受け取ったか、または何らかの誤りが発生するまで、コントロールは呼ぶプログラムに戻らないでしょうが、この体系は行き詰まりを非常に受けることがあります[セクション2.3.3を見てください]。 より洗練された実装は、数個RECEIVEのものがすぐに傑出していることを許可して、手紙が届くとき、Theseはいっぱいにされるでしょう。 この戦略は、より精巧な体系[ことによると非同期な]の費用における増強されたスループットが、手紙が受け取られたことを呼ぶプログラムに通知することを許可します。
If insufficient buffer space is given to reassemble a complete letter, an indication that the buffer holds a partial letter will be given; the buffer will be filled with as much data as it can hold.
完全な手紙を組み立て直すために不十分なバッファ領域を与えると、バッファが部分的な手紙を保持するという指示を与えるでしょう。 バッファは保持できるのと同じくらい多くのデータで満たされるでしょう。
The remaining parts of a partly delivered letter will be placed in buffers as they are made available via successive RECEIVES. If a number of RECEIVES are outstanding, they may be filled with parts of a single long letter or with at most one letter each. The event codes associated with each RECEIVE will indicate what is contained in the buffer.
それらを連続したRECEIVESを通して利用可能にするとき、一部提供された手紙の残存部分をバッファに置くでしょう。 多くのRECEIVESが傑出しているなら、彼らは部品でただ一つの長い文字か高々それぞれ1つの文字で満たされるかもしれません。 各RECEIVEに関連しているイベントコードはバッファに含まれていることを示すでしょう。
To distinguish among several outstanding RECEIVES, and to take care of the case that a letter is smaller than the buffer supplied, the event code is accompanied by both a buffer pointer and a byte count indicating the actual length of the letter received.
数個の傑出しているRECEIVESの中で区別して、バッファが供給したより小さく、イベントコードがバッファ指針とバイト・カウントの両方によって伴われることに手紙がそうであるケースに注意するために、手紙の実際の長さを示すのは受信されました。
Cerf, Dalal & Sunshine [Page 9] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[9ページ]RFC675仕様
The semantics of the INTERRUPT system call are discussed later, but this call can have an effect on outstanding RECEIVES. When the TCP receives an INTERRUPT, it will flush all data currently queued up awaiting receipt by the receiving process. If no data is waiting, but several buffers have been made available by anticipatory RECEIVE commands, these buffers are returned to the process with an error indicating that any data that might have been placed in those buffers has been flushed. This enables the receiving process to synchronize its RECEIVES with the interrupt. That is, the process can distinguish between RECEIVES issued before the receipt of the INTERRUPT and these issued afterwards.
後でINTERRUPTシステムコールの意味論について議論しますが、この呼び出しは傑出しているRECEIVESに影響を与えることができます。 TCPがINTERRUPTを受けるとき、それは現在受信プロセスで領収書を待ちながら列を作られているすべてのデータを洗い流すでしょう。 データが全く待っていませんが、予期的なRECEIVEコマンドでいくつかのバッファを利用可能にしたなら、誤りが、それらのバッファに置かれたどんなデータも洗い流してあるのを示していて、これらのバッファをプロセスに返します。 これは、受信プロセスが中断にRECEIVESを連動させるのを可能にします。 すなわち、プロセスはINTERRUPTの領収書の前で発行されたRECEIVESとその後発行されたこれらを見分けることができます。
Responses from the TCP which may occur as a result of this call are detailed in section 2.4.
この呼び出しの結果、起こるかもしれないTCPからの応答はセクション2.4で詳細です。
2.3.5 CLOSE CONNECTION
2.3.5 浅からぬ関係
Format: CLOSE(local connection name)
形式: 閉鎖(市内接続名)
This command causes the connection specified to be closed. If the connection is not open or the calling process is not authorized to use this connection, an error is returned. Any unfilled receive buffers or pending send buffers will be returned to the user with event codes indicating they were aborted due to the CLOSE. Users should wait for event codes for each SEND before closing the connection if they wish to be certain that all letters were successfully delivered.
このコマンドは閉じられるために指定された接続を引き起こします。 接続がオープンでないか、または呼び出しプロセスがこの接続を使用するのが認可されないなら、誤りは返されます。 バッファを送ってください。いずれも受信バッファを非充填した、未定である、イベントコードが、それらがCLOSEのため中止されたのを示していて、ユーザに返すでしょう。 彼らがすべての手紙が首尾よく提供されたのを確信するようになりたがっているなら接続を終える前に、ユーザは各SENDのためにイベントコードを待つべきです。
The user may CLOSE the connection at any time on his own initiative, or in response to various prompts from the TCP [remote close executed, transmission timeout exceeded, destination inaccessible].
ユーザは彼自身のイニシアチブのときにいつでもであることにおける、または、TCPからの様々なプロンプトに対応した接続[実行されたリモート閉鎖、タイムアウトが超えていたトランスミッション、近づきがたい目的地]のCLOSEがそうするかもしれません。
Because closing a connection requires communication with the foreign TCP, connections may remain in the closing state for a short time. Attempts to reopen the connection before the TCP replies to the CLOSE command will result in errors.
接続を終えるのが外国TCPとのコミュニケーションを必要とするので、接続は短い間終わりの州に留まるかもしれません。 TCPがCLOSEコマンドに答える前に接続を再開させる試みは誤りをもたらすでしょう。
Responses from the TCP which may occur as a result of this call are detailed in section 2.4.
この呼び出しの結果、起こるかもしれないTCPからの応答はセクション2.4で詳細です。
2.3.6 INTERRUPT
2.3.6 中断
Format: INTERRUPT(local connection name)
形式: 中断(市内接続名)
A special control signal is sent to the destination indicating an interrupt condition. This facility can be used to simulate "break" signals from terminals or error or completion codes from I/O devices, for example. The semantics of this signal to the receiving process
中断状態を示す目的地に特別な制御信号を送ります。 端末か誤りからの「中断」信号か例えば、入出力デバイスからの完了コードをシミュレートするのにこの施設を使用できます。 受信プロセスへのこの信号の意味論
Cerf, Dalal & Sunshine [Page 10] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[10ページ]RFC675仕様
are unspecified. The receiving TCP will signal the interrupt to the receiving process immediately upon receipt, and will also flush any outstanding letters waiting to be delivered. Since it is possib1e to tell where in the letter stream this command was invoked, it is possible for the receiving TCP to flush only preceding data. The sending TCP will flush any letters pending transmission, returning a special error code to indicate the flush.
不特定。 受信TCPはすぐ領収書の受信プロセスに中断に合図して、また、提供されるのを待つどんな傑出している手紙も洗い流すでしょう。 それが手紙ストリームでは、このコマンドがどこに呼び出されたかを言うpossib1eであるので、受信TCPが洗い流すのは、データに先行するだけでありながら、可能です。 水洗を示すために特別なエラーコードを返して、発信しているTCPはトランスミッションまでどんな手紙も洗い流すでしょう。
If the connection is not open or the calling process is not authorized to use this connection, an error is returned.
接続がオープンでないか、または呼び出しプロセスがこの接続を使用するのが認可されないなら、誤りは返されます。
Responses from the TCP which may occur as a result of this call are detailed in section 2.4.
この呼び出しの結果、起こるかもしれないTCPからの応答はセクション2.4で詳細です。
2.3.7 STATUS
2.3.7 状態
Format: STATUS(local connection name)
形式: 状態(市内接続名)
This command returns a data block containing the following information:
このコマンドは以下の情報を含むデータ・ブロックを返します:
local socket, foreign socket, local connection name, receive window,
send window, connection state, number of letters awaiting
acknowledgment, number of letters pending receipt [including partial
ones], default transmission timeout
地方のソケット、外国ソケット、市内接続名、窓を受けてください、そして、窓を送ってください、と接続は述べます、承認を待つ手紙の数、領収書まで手紙の数[部分的なものを含んでいて]、デフォルトトランスミッションタイムアウト
Depending on the state of the connection, some of this information
may not be available or meaningful. If the calling process is not
authorized to use this connection, an error is returned. This
prevents unauthorized processes from gaining information about a
connection.
接続の状態によって、この情報のいくつかが、利用可能であるか、または重要でないかもしれません。 呼び出しプロセスがこの接続を使用するのが認可されないなら、誤りは返されます。 これは、権限のないプロセスが接続に関して情報を得るのを防ぎます。
Responses from the TCP which may occur as a result of this call are
detailed in section 2.4.
この呼び出しの結果、起こるかもしれないTCPからの応答はセクション2.4で詳細です。
2.4 TCP TO USER MESSAGES
2.4 ユーザメッセージへのTCP
2.4.1 TYPE CODES
2.4.1 コードをタイプしてください。
All messages include a type code which identifies the type of user
call to which the message applies. Types are:
すべてのメッセージがメッセージが適用されるユーザ呼び出しのタイプを特定するタイプコードを含んでいます。 タイプは以下の通りです。
0 - General message, does not apply to a particular user call
0--一般メッセージは特定のユーザ呼び出しに適用されません。
1 - Applies to OPEN
1--、開くのに申し込みます。
2 - Applies to CLOSE
2--、閉じるのに申し込みます。
Cerf, Dalal & Sunshine [Page 11] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[11ページ]RFC675仕様
3 - Applies to INTERRUPT
3--、中断するのに申し込みます。
10 - Applies to SEND
10--、発信するのに申し込みます。
20 - Applies to RECEIVE
20--、受信するのに申し込みます。
30 - Applies to STATUS
30--、状態に適用します。
2.4.2 MESSAGE FORMAT [notional]
2.4.2 メッセージ・フォーマット[概念的]です。
All messages include the following three fields:
すべてのメッセージが以下の3つの分野を含んでいます:
Type code
コードをタイプしてください。
Local connection name
市内接続名
Event code
イベントコード
For message types 0-3 [General, Open, Close, Interrupt] only these three fields are necessary.
メッセージタイプ0-3[一般、オープン、Close、Interrupt]において、これらの3つの分野だけが必要です。
For message type 10 [Send] one additional field is necessary:
メッセージタイプ10[発信します]において、1つの追加分野が必要です:
Buffer address
バッファアドレス
For message type 20 [Receive] three additional fields are necessary:
メッセージタイプ20[受信します]において、3つの追加分野が必要です:
Buffer address
バッファアドレス
Byte count
バイト・カウント
End-of-letter flag
手紙の端の旗
For message type 30 [status] additional data might include;
メッセージに関しては、追加データが含むかもしれない30[状態]をタイプしてください。
Local socket, foreign socket
地方のソケット、外国ソケット
Send window [measures buffer space at foreign TCP]
窓を送ってください。[外国TCPでバッファ領域を測定します]
Receive window [measures buffer space at local TCP]
窓を受けてください。[地方のTCPでバッファ領域を測定します]
Connection state [see section 4.3.6]
接続状態[セクション4.3.6を見ます]
Number of letters awaiting acknowledgment
承認を待つ手紙の数
Number of letters awaiting receipt
領収書を待つ手紙の数
Retransmission timeout
再送タイムアウト
Cerf, Dalal & Sunshine [Page 12] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[12ページ]RFC675仕様
2.4.3 EVENT CODES
2.4.3 イベントコード
The event code specifies the particular event that the TCP wishes to communicate to the user.
イベントコードはTCPがユーザに伝えたがっている特定のイベントを指定します。
In addition to the event code, three flags may be useful to classify the event into major categories and facilitate event processing by the user:
イベントコードに加えて、3個の旗がイベントを大範疇に分類して、ユーザでイベント処理を容易にするために役に立つかもしれません:
E flag: set if event is an error
E旗: イベントが誤りであるなら、セットします。
L/F flag: indicates whether event was generated by Local TCP, or
Foreign TCP or network
L/F旗: イベントがLocal TCP、Foreign TCPまたはネットワークによって生成されたかどうかを示します。
P/T flag: indicates whether the event is Permanent or Temporary
[retry may succeed]
P/T旗: イベントがPermanentかそれともTemporaryであるかを示します。[再試行は成功するかもしれません]
Events are encoded into 8 bits with the high order bits set to indicate the state of the E, L/F, and P/T flags, respectively.
イベントはビットがEの状態、L/F、およびP/T旗を示すようにそれぞれ設定する高位で8ビットにコード化されます。
Events specified so far are listed below with their codes and flag settings. A * means a flag does not apply or can take both values for this event. Additional events may be defined in the course of experimentation.
今までのところ指定されているイベントは以下にそれらのコードと旗の設定に記載されています。 *は、旗が適用されないことを意味するか、またはこのイベントに両方の値を取ることができます。 追加イベントは実験の間に定義されるかもしれません。
0 0** general success
0 0**一般的な成功
1 ELP connection illegal for this process
このプロセスのための1人のELP接続不法入国者
2 OF* unspecified foreign socket has become bound
2OF*の不特定の外国ソケットは制限されるようになりました。
3 ELP connection not open
3 戸外ではなく、ELP接続
4 ELT no room for TCB
4ELTノー、はTCBのために同居します。
5 ELT foreign socket unspecified
5のELTの外国ソケット不特定です。
6 ELP connection already open
EFP unacceptable SYN [or SYN/ACK] arrived at foreign
TCP. Note: This is not a misprint, the local meaning is different
from foreign.
6 ELP接続の既に開いているEFP容認できないSYN[または、SYN/ACK]は外国TCPに到着しました。 以下に注意してください。 これが誤植でない、特定の意味は外国と異なっています。
7 EFP connection does not exist at foreign TCP
7 EFP接続は外国TCPに存在していません。
8 EFT foreign TCP inaccessible [may have subcases]
8 近づきがたいEFT外国TCP[「副-ケース」を持っているかもしれません]
9 ELT retransmission timeout
9 ELT再送タイムアウト
Cerf, Dalal & Sunshine [Page 13] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[13ページ]RFC675仕様
10 E*P buffer flushed due to interrupt
中断で紅潮した10E*のPバッファ
11 OF* interrupt to user
11 OF*はユーザに中断します。
12 **P connection closing
12**P接続閉鎖
13 E** general error
13Eの**一般的なエラー
14 E*P connection reset
14ユーロ*のP接続リセット
Possible events for each message type are as follows:
それぞれのメッセージタイプに、可能なイベントは以下の通りです:
Type 0[general]: 2,11,12,14
0[一般的な]はタイプします: 2,11,12,14
Type 1[open]: 0,1,4,6,13
タイプ1[開いている]: 0,1,4,6,13
Type 2[close]: 0,1,3,13
[近いところで]2をタイプしてください: 0,1,3,13
Type 3[interrupt]: 0,1,3,5,7,8,9,12,13
3[中断する]はタイプします: 0,1,3,5,7,8,9,12,13
Type 10[send]: 0,1,3,5,7,8,9,10,11,12,13
10[発信する]はタイプします: 0,1,3,5,7,8,9,10,11,12,13
Type 20[receive]: 0,1,3,10,12,13
20[受信する]はタイプします: 0,1,3,10,12,13
Type 30[status]: 0,1,13
30[状態]はタイプします: 0,1,13
Note that events 6(foreign), 7, 8 are generated at the foreign TCP or in the network[s], and these same codes are used in the error field of the internet packet [see section 4.2.1].
イベント6(外国)、7、8が外国TCPにおいて、または、ネットワーク[s]で生成されて、これらの同じコードがインターネットパケットの誤り分野で使用されることに注意してください[セクション4.2.1を見てください]。
3. HIGHER LEVEL PROTOCOLS
3. より高い平らなプロトコル
3.1 INTRODUCTION
3.1 序論
It is envisioned that the TCP will be able to support higher level protocols efficiently. It should be easy to interface existing ARPANET protocols like TELNET and FTP to the TCP.
それは思い描かれます。TCPは、より高いレベルがプロトコルであると効率的にサポートすることができるでしょう。 TELNETとFTPのような既存のアルパネットプロトコルをTCPに連結するのは簡単であるはずです。
3.2 WELL KNOWN SOCKETS
3.2 よく知られているソケット
At some point, a set of well known 24 bit port numbers must be picked. The type of service associated with the well known ports might include:
何らかのポイントでは、1セットの24ビットのよく知られているポートナンバーを選ばなければなりません。 よく知られているポートに関連しているサービスのタイプは以下を入れるかもしれません。
(a) Logger
(a) きこり
(b) FTP (File transfer protocol)
(b) FTP(ファイル転送プロトコル)
Cerf, Dalal & Sunshine [Page 14] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[14ページ]RFC675仕様
(c) RJE (Remote job entry)
(c) RJE(リモートジョブエントリ)
(d) Host status
(d) ホスト状態
(e) TTY Test
(e) TTYテスト
(f) HELP - descriptive, interactive system documentation
(f) ヘルプ--描写的で、対話的なシステム文書
WE RESERVE WELL KNOWN SOCKET 0 (24 bits of 0) for global messages destined for a particular TCP but not related to any particular connection. We imagine that this socket would be used for unusual TCP synchronization (e.g. RESET ALL) or for testing purposes (e.g. sending letters to TRASHCAN or ECHO). This does not conflict with the usage that if a socket is 0, it is unspecified, since no user can SEND, CLOSE, or INTERRUPT on socket 0.
グローバルなメッセージのためのWE RESERVE WELL KNOWN SOCKET0(0の24ビット)は少しの特定の接続にも特定のTCPのために運命づけられましたが、関連しませんでした。 私たちは、このソケットが珍しいTCP同期(例えば、RESET ALL)かテスト目的(例えば、手紙をTRASHCANに送るか、ECHO)に使用されると想像します。 これはソケットであるなら0である用法と衝突しないで、それは不特定です、どんなユーザもソケット0の上のSEND、CLOSE、またはINTERRUPTをそうすることができないので
3.3 RECONNECTION PROTOCOL (RCP)
3.3 再接続プロトコル(RCP)
Port identifiers fall into two categories: permanent and transient. For example, a Logger process is generally assigned a port identifier that is fixed and well known. Transient processes will in general have ID's which are dynamically assigned.
ポート識別子は2つのカテゴリになります: 永久的であって、一時的です。 例えば、一般に、固定されて、よく知られているポート識別子はLoggerプロセスに割り当てられます。 一般に、一時的なプロセスには、ダイナミックに割り当てられるIDのものがあるでしょう。
In the distributed processing environment of the network, two processes that don't have well known port identifiers may often wish to communicate. This can be achieved with the help of a well known process using a reconnection protocol. Such a protocol is briefly outlined using the communication facilities provided by the TCP. It essentially provides a mechanism by which port identifiers are exchanged in order to establish a connection between a pair of sockets.
ネットワークの分散処理環境で、よく知られているポート識別子を持っていない2つのプロセスがしばしば交信したがっているかもしれません。 よく知られているプロセスの助けが再接続プロトコルを使用している状態で、これを達成できます。 そのようなプロトコルは、TCPによって提供された通信機器を使用することで簡潔に概説されています。 それは本質的には、ポート識別子が1組のソケットの間に取引関係を築くために交換されるメカニズムを提供します。
Such a protoco1 can be used to achieve the dynamic establishment of new connections in order to have multiple processes solving a problem cooperatively, or to provide a user process access to a server process via a logger, when the logger's end of the connection can not be invisibly passed to the server process.
複数のプロセスを協力して問題を解かせるために新しい接続のダイナミックな設立を達成するか、またはきこりを通してサーバプロセスへのユーザ・プロセスアクセスを提供するのにそのようなprotoco1を使用できます、目につかないほどきこりの接続の終わりをサーバプロセスに渡すことができないとき。
A paper on this subject by R. Schantz [SCHA74] discusses some of the issues associated with reconnection, and some of the ideas contained therein went into the design of the protocol outlined below.
R.Schantz[SCHA74]によるこの問題に関する論文は再接続に関連している問題のいくつかについて議論します、そして、そこに含まれた考えのいくつかが以下に概説されたプロトコルのデザインを調べました。
In the ARPANET, a protocol was implemented which would allow a process to connect to a well known socket, thus making an implicit request for service, and then be switched to another socket so that the well known socket could be freed for use by others. Since sockets
アルパネットでは、他のものが使用のためによく知られているソケットを解放できるように、プロセスがよく知られているソケットに接続して、その結果、サービスを求める暗黙の要求をするのを許容して、次に別のソケットに切り換えられるプロトコルは、実装されました。 ソケット以来
Cerf, Dalal & Sunshine [Page 15] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[15ページ]RFC675仕様
in our TCP are permitted to have connections with more than one foreign socket, this facility may not be explicitly needed (i.e. connections <A,B> and <A,C> are distinguishable).
私たちのTCPでは、外国ソケット、この施設がそうする1つ以上との接続を明らかに必要とさせないことが(すなわち、接続<A、B>と<A、C>は区別可能です)許可されています。
However. the well known socket may be in one network and the actual service socket(s) may be in another network (or at least in another TCP). Thus, the invisible switching of a connection from one port to another within a TCP may not be sufficient as an "Initial Connection Protocol". We imagine that a process wishes to use socket N1.T1.Q to access well known socket N2.T2.P. However, the process associated with socket N2.T2.P will actually start up a new process somewhere which will use N3.T3.S as its server socket. The N(i) and T(i) may be distinct or the same. The user will send to N2.T2.P the relevant user information such as user name, password, and account. The server will start up the server process and send to N1.T1.Q the actual service socket ldentif1er: N3.T3.S. The connection (N1.TI.Q,N2.T2.P) can then be closed, and the user can do a RECEIVE on (N1.T1.Q,N3.T3.S). The serving process can SEND on (N3.T3.S,N1.T1.Q). There are many variations on this scheme, some involving the user process doing a RECEIVE on a different socket (e.g. (N1.T1.X,U.U.U)) with the server doing SEND on (N3.T3.S,N1.T1.X). Without showing all the detail of synchronization of sequence numbers and the like, we can illustrate the exchange as shown below.
しかしながら、1つのネットワークには. よく知られているソケットがあるかもしれません、そして、別のネットワーク(または少なくとも別のTCPで)には就航ソケットがあるかもしれません。 したがって、TCPの中の接続の目に見えない1つのポートから別のポートまでの切り換えは「初期の接続プロトコル」として十分でないかもしれません。 私たちは、プロセスがよく知られているソケットN2.T2.P. HoweverにアクセスするのにソケットN1.T1.Qを使用したがっていると想像して、ソケットN2.T2.Pに関連しているプロセスは実際にどこかのサーバソケットとしてN3.T3.Sを使用するニュープロセスを立ち上げるでしょう。 N(i)とT(i)は異なるか、または同じであるかもしれません。 ユーザはユーザ名や、パスワードや、アカウントなどの関連ユーザー情報をN2.T2.Pに送るでしょう。 サーバは、サーバプロセスを立ち上げて、就航ソケットldentif1erをN1.T1.Qに送るでしょう: 次に、接続(N1.TI.Q、N2.T2.P)のN3.T3.S.を閉じることができます、そして、ユーザは(N1.T1.Q、N3.T3.S)でRECEIVEができます。 給仕プロセスは(N3.T3.S、N1.T1.Q)のSENDをそうすることができます。 この体系の多くの変化があります、何かが異なったソケット(例えば、(N1.T1.X、U.U.U))でRECEIVEをするユーザ・プロセスに(N3.T3.S、N1.T1.X)でSENDをするサーバにかかわって。 一連番号と同様のものの同期のすべての詳細を示しているというわけではなくて、私たちは以下に示すように交換を例証できます。
USER SERVER
ユーザサーバ
1. RECEIVE(N2.T2.P,U.U.U)
1. 受信してください。(N2.T2.P、U.U.U)
1. SEND (N1.T1.Q,N2.T2.P)==>
1. (N1.T1.Q、N2.T2.P)=>を送ってください。
<== 2. SEND(N2.T2.P,N1.T1.Q)
<= 2. 発信してください。(N2.T2.P、N1.T1.Q)
With "N3.T3.S" as data
データとしての「N3.T3.S」と共に
2. RECEIVE(N1.T1.Q,N2.T2.P)
2. 受信してください。(N1.T1.Q、N2.T2.P)
3. CLOSE(N1.T1.Q,N2.T2.P)==>
3. (N1.T1.Q、N2.T2.P)=>を閉じてください。
<:= 3. CLOSE(N2.T2.P,N1.T1.Q)
<: =3。 閉鎖(N2.T2.P、N1.T1.Q)
4. RECEIVE(N1.T1.Q,N3.T3.S)
4. 受信してください。(N1.T1.Q、N3.T3.S)
<== 4. SEND(N3.T3.S,N1.T1.Q)
<= 4. 発信してください。(N3.T3.S、N1.T1.Q)
At this point, a connection is open between N1.T1.Q and N3.T3.S. A variation might be to have the user do an extra RECEIVE on (N1.T1.X,U.U.U) and have the data "N1.T1.X" be sent in the first user SEND. Then, the server can start up the real serving process and do a
ここに、接続はN1.T1.QとN3.T3.S.の間でオープンです。A変化はユーザが(N1.T1.X、U.U.U)で付加的なRECEIVEをして、データ"N1.T1.X"を送らせるのを持つために、最初のユーザが発信するということであるかもしれません。 次に、サーバは、本当の給仕プロセスを立ち上げて、aができます。
Cerf, Dalal & Sunshine [Page 16] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[16ページ]RFC675仕様
SEND on (N3.T3.S,N1.T1.X) without having to send the "N3.T3.S" data to the user. Or perhaps both server and receiver exchange this data, to assure security of the ultimate connection (i.e. some wild process might try to connect to N1.T1.X if it is merely RECEIVING on foreign socket U.U.U.).
ユーザへの(N3.T3.S、N1.T1.X)「N3.T3.S」データの発信する必要はなくてSEND。 または、恐らくサーバと受信機の両方が、究極の接続をセキュリティに保証するためにこのデータを交換します(すなわちあるワイルドなプロセスがそれが単に外国ソケットU.U.U.のRECEIVINGであるならN1.T1.Xに接続しようとするかもしれません)。
We do not propose any specific reconnection protocol here, but leave this to further deliberation, since it is really a user level protocol issue.
私たちはここでどんな特定の再接続プロトコルも提案しませんが、これが熟考を促進するのを残してください、それが本当にユーザレベルプロトコル問題であるので。
4. TCP IMPLEMENTATION
4. TCP実装
4.1 INTRODUCTION
4.1 序論
Conceptually, the TCP is made up of several processes. Some of these deal with USER/TCP commands, and others with packets arriving from the network. The TCP also has an internal measurement facility which can be activated remotely.
概念的に、TCPはいくつかのプロセスで作られます。 パケットがネットワークから到着している状態で、これらの或るものはUSER/TCPコマンド、および他のものに対応します。 また、TCPには、離れて動かすことができる内部の測定施設があります。
Any particular TCP could be viewed in a number of ways. It could be implemented as an independent process, servicing many user processes. It could be viewed as a set of re-entrant library routines which share a common interface to the local PSN, and common buffer storage. It could even be viewed as a set of processes, some handling the user, some the input of packets from the net, and some the output of packets to the net.
多くの方法でどんな特定のTCPも見ることができました。 多くのユーザ・プロセスを修理して、独立しているプロセスとしてそれを実装することができました。 1セットのリエントラントライブラリ・ルーチンとしてそれを見なすことができました(地方のPSN、および一般的な緩衝記憶装置と一般的なインタフェースを共有します)。 何かがユーザを扱って、セットされたaが処理されて、何かがネットからのパケットの入力であり、何かがネットへのパケットの出力であるので、それを見ることさえできました。
4.2 TCP DATA STRUCTURES
4.2 TCPデータ構造
4.2.1 INTERNETWORK PACKET FONMAT
4.2.1 インターネットワークパケットFONMAT
8 bits: Internet information
8ビット: インターネット情報
2 bits: Reserved for local PSN use
2ビット: 地方のPSN使用のために、予約されます。
2 bits: Header format (11 in binary)
2ビット: ヘッダー形式(バイナリーの11)
4 bits: Protocol version number
4ビット: プロトコルバージョン番号
8 bits: Header length in octets (32 is the current value)
8ビット: 八重奏におけるヘッダ長(32は現行価値です)
16 bits: Length of text in octets
16ビット: 八重奏における、テキストの長さ
32 bits: Packet sequence number
32ビット: パケット一連番号
32 bits: Acknowledgment number (i.e. sequence number of next octet expected).
32ビット: 確認応答番号(すなわち、予想された次の八重奏の一連番号)。
Cerf, Dalal & Sunshine [Page 17] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[17ページ]RFC675仕様
16 bits: Window size (in octets)
16ビット: ウィンドウサイズ(八重奏における)
16 bits: Control Information
16ビット: 制御情報
Listed from high to low order:
記載される高値から下位まで:
SYN: Request to synchronize sending sequence numbers
SYN: 送付一連番号を同期させるという要求
ACK: There is a valid acknowledgment in the 32 bit ACK field
ACK: 有効な承認が32ビットのACK分野にあります。
FIN: Sender will stop SENDing and RECEIVEing on this connection
フィン: 送付者はこの接続にSENDingとRECEIVEingを止めるでしょう。
DSN: The sender has stopped using sequence numbers and wants to
initiate a new sequence number for sending.
DSN: 送付者は、一連番号を使用するのを止めて、送付のために新しい一連番号を開始したがっています。
EOS: This packet is the end of a segment and therefore has a
checksum in the 16 bit checksum field. If this bit is not set, the
16 bit checksum field is to be ignored. The bit is usually set,
but if fragmentation at a GATEWAY occurs, the packets preceding
the last one will not have checksums, and the last packet will
have the checksum for the entire original fragment (segment) as it
was calculated by the sending TCP.
エオス: このパケットは、セグメントの終わりであり、したがって、16ビットのチェックサム分野にチェックサムを持っています。 このビットが設定されないなら、16ビットのチェックサム分野は無視されることです。 ゲートウェイでの断片化が起こると、最後のものに先行するパケットはチェックサムを持たないでしょう、そして、ビットは通常設定されますが、最後のパケットには、それが発信しているTCPによって計算されたように全体のオリジナルの断片(セグメント)のためのチェックサムがあるでしょう。
EOL: This packet contains the last fragment of a letter. The EOS
bit will always be set in this case.
EOL: このパケットは手紙の最後の断片を含んでいます。 EOSビットはこの場合いつも設定されるでしょう。
INT: The sender wants to INTERRUPT on this connection.
INT: 送付者はこの接続のときにINTERRUPTに欲しいです。
XXX: six (6) unused control bits
XXX: 未使用の6(6)コントロールビット
OD: three (3) bits of control dispatch:
以下を過量に与えてください。 コントロールの3(3)ビットを急いでいます:
000: Null (the control octet contents should be ignored}
000: ヌル、(コントロール八重奏コンテンツは無視されるべきです。
001: Event Code is present in the control octet. These were
defined in section 2.4.3.
001: イベントCodeはコントロール八重奏で存在しています。 これらはセクション2.4.3で定義されました。
010: Special Functions
010: 特別な機能
011: Reject (codes as yet undefined)
011: 廃棄物(まだ未定義であるとしてのコード)
1XX: Unused
1XX: 未使用
8 bits: Control Data Octet
8ビット: 制御データ八重奏
If CD is 000 then this octet is to be ignored.
CDが000であるなら、この八重奏は無視されることです。
Cerf, Dalal & Sunshine [Page 18] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[18ページ]RFC675仕様
If CD is 001, this octet contains event codes defined in section
2.4.3
CDが001であるなら、この八重奏はセクション2.4.3で定義されたイベントコードを含んでいます。
If CD is 010, this octet contains a special function code as
defined below:
CDが010であるなら、この八重奏は以下で定義されるように特別な機能コードを含んでいます:
0: RESET all connections between Source and Destination TCPs
0: RESETは皆、SourceとDestination TCPsとの接続です。
l: RESET the specific connection referenced in this packet
l: このパケットで参照をつけられる特定の接続のRESET
2: ECHO return packet to sender with the special function code
ECHOR (Echo Reply).
2: ECHOは特別な機能コードECHOR(エコーReply)をもっている送付者にパケットを返します。
3: QUERY Query status of connection referenced in this packet
3: このパケットで参照をつけられる接続のQUERY Query状態
4: STATUS Reply to QUERY with requested status.
4: 要求された状態があるQUERYへのSTATUS Reply。
5: ECHOR Echo Reply
5: ECHORエコー・リプライ
6: TRASH Discard packet without acknowledgment
6: 承認のないTRASH Discardパケット
>6: Unused
>6: 未使用
Note: Special function packets not pertaining to a particular
connection [RESET all, ECHO, ECHOR, and TRASH] are normally
sent using socket zero as described in section 3.2.
以下に注意してください。 特定の接続に関係しない特別な機能パケット、[RESET、すべて、ECHO、ECHOR、およびTRASH] 通常、セクション3.2で説明されるようにソケットゼロを使用させます。
If CD is 01l, this octet contains an as yet undefined REJECT code.
CDが01l、この八重奏である、含有、まだ未定義のREJECTコード。
If CD is 1XX, this octet is undefined.
CDが1XXであるなら、この八重奏は未定義です。
4 bits: Length of destination network address in 4 bit units (current value is 1)
4ビット: 4ビットのユニットの目的地ネットワーク・アドレスの長さ(現行価値は1です)
4 bits: Destination network address
4ビット: 目的地ネットワーク・アドレス
1010-1111 are addresses of ARPANET, UCL, CYCLADES, NPL, CADC, and
EPSS respectively.
1010-1111は、それぞれアルパネットのアドレスと、UCL、キクラデス諸島と、NPLと、CADCと、EPSSです。
16 bits: Destination TCP address
16ビット: 送付先TCPアドレス
8 bits: Padding
8ビット: 詰め物
4 bits: length of source network address in 4 bit units (current value is 1)
4ビット: 4ビットのユニットのソースネットワーク・アドレスの長さ(現行価値は1です)
4 bits: source network address (as for destination address)
4ビット: ソースネットワーク・アドレス(送付先アドレスのような)
Cerf, Dalal & Sunshine [Page 19] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[19ページ]RFC675仕様
16 bits: Source TCP address
16ビット: ソースTCPアドレス
24 bits: Destination port address
24ビット: 仕向港アドレス
24 bits: Source port address
24ビット: ソースポートアドレス
16 bits: Checksum (if EOS bit is set)
16ビット: チェックサム(EOSビットが設定されるなら)
4.2.2 TRANSMISSION CONTROL BLOCK
4.2.2 トランスミッション制御ブロック
It is highly likely that any implementation will include shared data structures among parts of the TCP and some asynchronous means of signaling users when letters have been delivered.
手紙が提供されたとき、どんな実装もTCPの部分とユーザに合図するいくつかの非同期な手段の中に共有データ構造を非常に含みそうでしょう。
One typical data structure is the Transmission Control Block (TCB) which is created and maintained during the lifetime of a given connection. The TCB contains the following information (field sizes are notional only and may vary from one implementation to another):
1つの典型的なデータ構造が与えられた接続の生涯作成されて、維持されるTransmission Control Block(TCB)です。 TCBが以下の情報を含んでいる、(分野サイズが概念的である、唯一、1つの実装から別のものに異なるかもしれない、)、:
16 bits: Local connection name
16ビット: 市内接続名
48 bits: Local socket
48ビット: 地方のソケット
48 bits: Foreign socket
48ビット: 外国ソケット
16 bits: Receive window size in octets
16ビット: 八重奏におけるレシーブ・ウィンドウ・サイズ
32 bits: Receive left window edge (next sequence number expected)
32ビット: 左の窓の優勢を受けてください。(予想された次の一連番号)
16 bits: Receive packet buffer size of TCB (may be less than
window)
16ビット: TCBのパケットバッファサイズを受けてください。(窓より少ないかもしれません)
16 bits: Send window size in octets
16ビット: 八重奏におけるウィンドウサイズを送ってください。
32 bits: Send left window edge (earliest unacknowledged octet)
32ビット: 左の窓の優勢を送ってください。(最も早い不承認の八重奏)
32 bits: Next packet sequence number
32ビット: 次のパケット一連番号
16 bits: Send packet buffer size of TCB (may be less than window)
16ビット: TCBのパケットバッファサイズを送ってください。(窓より少ないかもしれません)
8 bits: Connection state
8ビット: 接続状態
E/C - 1 if TCP has been synchronized at least once (i.e. has
been established, else O, meaning it is closed; this bit is
reset after FINS are exchanged and the user has done a CLOSE).
The bit is not reset if the connection is only desynchronized
on send or receive or both directions.
E/C--1 TCPが少なくとも一度(すなわち、それは閉じられます; Finsを交換して、ユーザがCLOSEをした後にこのビットがリセットされることを意味して、確立してほかのOであった)連動したことがあるなら。 ビットは接続のときに反連動するだけであるなら、リセットに発信するか、または受信されるということではありません両方が方向です。
Cerf, Dalal & Sunshine [Page 20] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[20ページ]RFC675仕様
SS - SYNCed on send side (if set) else desynchronized
SS--、SYNCed、オンである、ほかに、反連動していた状態で側(設定されるなら)を送ってください。
SR - SYNCed on receive side (if set, else desynchronized)
SR--、SYNCed、側は受信します。(ほかに反連動していた状態で設定されるなら)
16 bits: Special flags
16ビット: 特別な旗
S1 - SYN sent if set
S1--設定されるなら送られたSYN
S2 - SYN verified if set
S2--設定されるなら確かめられたSYN
R - SYN received if set
R--設定されるなら受け取られたSYN
Y - FIN sent if set
Y--設定されるなら送られたFIN
C - CLOSE from local user received if set
C--設定されるなら受け取られた地元のユーザからのCLOSE
U - Foreign socket unspecified if set
外国ソケット不特定の、しかし、設定しているu
SDS - Send side DSN sent if set
SDS--設定されるなら送られたサイドDSNを送ってください。
SDV - Send side DSN verified if set
SDV--設定されるなら確かめられたサイドDSNを送ってください。
RDR - Receive side DSN received if set
RDR--設定されるなら受け取られたサイドDSNを受けてください。
Initially, all bits are off [no pun intended] (i.e. SS, SR, E/C, S1, S2, R, F, C, SDS, SDV, RDR =0). When R is set, so is SR. When S1 and S2 are both set, so is SS. SR is reset when RDR is set. SS is reset when both SDS and SDV are set. These bits are used to keep track of connection state and to aid in arriving packet processing (e.g. Can sequence number be validated? Only if SR is set.).
初めは、すべてのビットが[意図しないだじゃれ全く](すなわち、SS、SR、E/C、S1、S2、R、F、C、SDS、SDV、RDR=0)にあります。 Rが設定されるとき、SRもそうです。 S1とS2がともに用意ができているとき、SSもそうです。 RDRが用意ができているとき、SRはリセットされます。 SDSとSDVの両方が用意ができているとき、SSはリセットされます。 これらのビットは、状態と到着パケットの援助への接続の道を処理させ続けるのに使用されます。(例えば、Can一連番号、有効にされますか? SRが用意ができている場合にだけ。).
16 bits: Retransmission timeout (in eighths of a second#]
16ビット: 再送タイムアウト(2番目の#の8分の1の]
16 bits: Head of Send buffer queue [buffers SENT from user to TCP, but not packetized]
16ビット: Sendバッファ待ち行列のヘッド[packetizedされないのを除いて、ユーザからTCPまでSENTをバッファリングします]
16 bits: Tail of Send buffer queue
16ビット: Sendバッファ待ち行列のテール
16 bits: Pointer to last octet packetized in partially packetized buffer (refers to the buffer at the head of the queue)
16ビット: 部分的にpacketizedされたバッファでpacketizedされた最後の八重奏への指針(待ち行列のヘッドのバッファを示します)
16 bits: Head of Send packet queue
16ビット: Sendパケット待ち行列のヘッド
16 bits: Tail of Send packet queue
16ビット: Sendパケット待ち行列のテール
16 bits: Head of Packetized buffer Queue
16ビット: PacketizedバッファQueueのヘッド
16 bits: Tail of Packetized buffer queue
16ビット: Packetizedバッファ待ち行列のテール
Cerf, Dalal & Sunshine [Page 21] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[21ページ]RFC675仕様
16 bits: Head of Retransmit packet queue
16ビット: Retransmitパケット待ち行列のヘッド
16 bits: Tail of Retransmit packet queue
16ビット: Retransmitパケット待ち行列のテール
16 bits: Head of Receive buffer queue [queue of buffers given by user to RECEIVE letters, but unfilled]
16ビット: Receiveバッファ待ち行列のヘッド[ユーザによってRECEIVE手紙に与えられていますが、非充填されたバッファの待ち行列]
16 bits: Tail of Receive buffer queue
16ビット: Receiveバッファ待ち行列のテール
16 bits: Head of Receive packet queue
16ビット: Receiveパケット待ち行列のヘッド
16 bits: Tail of receive packet queue
16ビット: ついて行く、パケット待ち行列を受けてください。
16 bits: Pointer to last contiguous receive packet
16ビット: 最終への隣接のポインタはパケットを受けます。
16 bits: Pointer to last octet filled in partly filled buffer
16ビット: 記入された最後の八重奏へのポインタはバッファを一部いっぱいにしました。
16 bits: Pointer to next octet to read from partly emptied packet
16ビット: 一部空にされたパケットから読む次の八重奏へのポインタ
[Note: The above two pointers refer to the head of the receive
buffer and receive packet queues respectively]
[注意: 上記の2個のポインタが受信バッファのヘッドについて言及して、それぞれパケット待ち行列を受けます]
16 bits: Forward TCB pointer
16ビット: 前進のTCBポインタ
16 bits: Backward TCB pointer
16ビット: 後方のTCBポインタ
4.3 CONNECTION MANAGEMENT
4.3 接続管理
4.3.1 INITIAL SEQUENCE NUMBER SELECTION
4.3.1 初期シーケンス番号選択
The protocol places no restriction on a particular connection being used over and over again. New instances of a connection will be referred to as incarnations of the connection. The problem that arises owing to this is, "how does the TCP identify duplicate packets from previous incarnations of the connection?". This problem becomes harmfully apparent if the connection is being opened and closed in quick succession, or if the connection breaks with loss of memory and is then reestablished.
プロトコルは幾重にも使用されている特定の接続に関して制限を全く課しません。 接続の新しい例は接続の肉体化と呼ばれるでしょう。 これで起こる問題は「TCPは接続の前の肉体化から写しパケットをどのように特定しますか?」ということです。 接続は迅速な継承かそれとも記憶喪失と分かれて、あるかどうかで、接続が次に、復職していた状態で開かれて、閉店しているなら、この問題は有害に明らかになります。
The essence of the solution [TOML74] is that the initial sequence number [ISN] must be chosen so that a particular sequence number can never refer to an "o1d" octet, Once the connection is established the sequencing mechanism provided by the TCP filters out duplicates.
解決策[TOML74]の本質は特定の一連番号が"o1d"八重奏、接続のOnceについて決して言及できないように[ISN]を選ばなければならない初期シーケンス番号が設立されて、TCPによって提供された配列メカニズムが写しを無視するということであるということです。
For an association to be established or initialized, the two TCP's must synchronize on each other's initial sequence numbers. Hence the solution requires a suitable mechanism for picking an initial sequence number [ISN], and a slightly involved handshake to exchange
設立されるべきであるか、または初期化するべき協会に関しては、2TCPのものは互いの初期シーケンス番号で連動しなければなりません。 したがって、解決策は、初期シーケンス番号[ISN]、および交換するわずかにかかわった握手を選ぶために適当なメカニズムを必要とします。
Cerf, Dalal & Sunshine [Page 22] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[22ページ]RFC675仕様
the ISN's. A "three way handshake" is necessary because sequence numbers are not tied to a global clock in the network, and TCP's may have different mechanisms for picking the ISN's. The receiver of the first SYN has no way of knowing whether the packet was an old delayed one or not, unless it remembers the last sequence number used on the connection which is not always possible, and so it must ask the sender to verify this SYN.
ISNのもの 「3、道の握手、」、一連番号がネットワークでグローバルな時計に結ばれないで、TCPのものにはISNを選ぶための異なったメカニズムがあるかもしれないので、必要です。 最初のSYNの受信機には、パケットが古い遅れたものであったかどうかを知る方法が全くありません、どれがいつも可能であるというわけではないかを接続のときに使用された最後の一連番号に覚えているのでこのSYNについて確かめるように送付者に頼んではいけない場合。
The "three way handshake" and the advantages of a "clock-driven" scheme are discussed in [TOML74]. More on the subject, and algorithms for implementing the clock-driven scheme can be found in [DALA74].
「3つの方法、」 「時計駆動」の計画の利点について議論する握手[TOML74]。 さらにこの件、および[DALA74]で時計駆動の計画を見つけることができる実行のためのアルゴリズムに関して。
4.3.2 ESTABLISHING A CONNECTION
4.3.2 取引関係を築くこと。
The "three way handshake" is essentially a unidirectional attempt to establish the connection, i.e. there is an initiator and a responder. The TCP's should however be able to establish the connection even if a simultaneous attempt is made by both TCP's to establish the connection. Simultaneous attempts are treated like "collisions" in "Aloha" systems and these conflicts are resolved into unidirectional attempts to establish the connection. This scheme was adopted because
「3、道の握手、」 本質的には単方向の試みるのは接続を確立することになっていて、すなわち、創始者と応答者がいます。 しかしながら、両方で同時の試みをしても、TCPのものは接続を確立するはずであることができます。接続を確立するTCPのもの 「アロハ」のシステムとこれらの闘争における「衝突」が接続を確立する単方向の試みに変えられるように同時の試みは扱われます。 この計画は採用されました。
(i) Connections will normally have a passive and an active end,
and so the mechanism should in most cases be as simple as
possible.
(i) コネクションズには受け身の端とアクティブな端が通常あるので、多くの場合、メカニズムはできるだけ簡単であるべきです。
(ii) It is easy to implement as special cases do not have to be
accounted for.
(ii) 特別なケースは原因にならされる必要はないようにそれは実行しやすいです。
The example below indicates what a three way handshake between TCP's A and B looks like
以下の例は、TCPのAとBの間の握手がどんな3風のように見えるかを示します。
A B
B
--> <SEQ x><SYN> -->
--><SEQ x><SYN>-->。
<-- <SEQ y><SYN, ACK x+l> <--
<--<SEQ y><SYN、ACK x+l><--
--> <SEQ x+1><ACK y+l><DATA BYTES> -->
--><SEQ x+1><ACK y+l><データ・バイト>-->。
The receiver of a "SYN" is able to determine whether the "SYN" was real (and not an old duplicate) when a positive "ACK" is returned for the receiver's "SYN,ACK" in response to the "SYN". The sender of a "SYN" gets verification on receipt of a "SYN,ACK" whose "ACK" part references the sequence number proposed in the original "SYN" [pun intended]. If the TCP is in the state where it is waiting for a response to its SYN, but gets a SYN instead, then it always thinks this is a collision and goes into the state prior to having sent the
"SYN"の受信機は、受信機のために積極的な"ACK"を返すとき、"SYN"が本当であったかどうかが(そして、古い写しでない)、"SYN"に対応した「SYN、ACK」であると決定できます。 "SYN"の送付者は一連番号がオリジナルの"SYN"で提案した「SYN、ACK」"ACK"部分参照を受け取り次第検証を得ます[意図していた状態で、だじゃれを言ってください]。 TCPがそれがSYNへの応答を待っていますが、代わりにSYNを手に入れる状態にあるなら、それは、いつもこれが衝突であると考えて、発信する前に、状態に入ります。
Cerf, Dalal & Sunshine [Page 23] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[23ページ]RFC675仕様
SYN, i.e. it forgets that it had sent a SYN. The TCP will try to establish the connection again after some time, unless it has to respond to an arriving SYN. Even if the wait times in the two TCPs are the same, the varying delays in network transmission will usually be adequate to avoid a collision on the next cycle of attempts to send SYN.
SYN、すなわち、SYNを送ったのは忘れられます。 TCPはいつか後に再び接続を確立しようとするでしょう、到着SYNに応じる必要はないなら。 2TCPsの待ち時間が同じであっても、通常、ネットワーク送信の異なった遅れは、SYNを送る試みの次のサイクルに衝突を避けるために適切になるでしょう。
When establishing a connection, the state of the TCP is represented by 3 bits --
取引関係を築くとき、TCPの州は3ビットによって代表されます--
S1 S2 R
S1 S2R
S1 = 1 -- SYN sent
S1=1--SYNは発信しました。
S2 = 1 -- My SYN verified
S2=1--確かめられた私のSYN
R = 1 -- SYN received
R=1--SYNは受信しました。
Some examples of attempts to establish the connection are now shown. The state of the connection is indicated when a change occurs. We specifically do not show the cases in which connection synchronization is carried out with packets containing both SYN and data. We do this to simplify the explanation, but we do not rule out an implementation which is capable of dealing with data arriving in the first packet (it has to be stored temporarily without acknowledgment or delivery to the user until the arriving SYN has been verified).
接続を確立する試みに関するいくつかの例が現在、示されます。 変化が起こるとき、接続の状態は示されます。 私たちは明確に、パケットがSYNとデータの両方を含んでいて接続同期が行われる場合を示しません。 私たちは説明を簡素化するためにこれをしますが、私たちは最初のパケットに到着するデータに対処できる実現を除外しません(到着しているSYNが確かめられるまで、それは承認も配送なしでユーザに一時格納されなければなりません)。
The "three way handshake" now looks like --
「3つの方法、」 現在が似ている握手--
A B
------------ ------------
S1 S2 R S1 S2 R
B------------ ------------ S1 S2R S1 S2R
0 0 0 0 0 0
0 0 0 0 0 0
--> <SEQ x><SYN> -->
--><SEQ x><SYN>-->。
1 0 0 0 0 1
1 0 0 0 0 1
<-- <SEQ y><SYN, ACK x+l> <--
<--<SEQ y><SYN、ACK x+l><--
1 1 1 1 0 1
1 1 1 1 0 1
--> <SEQ x+1><ACK y+1>(DATA OCTETS) -->
--><SEQ x+1><ACK y+1>(データ八重奏)-->。
1 1 1 1 1 1
1 1 1 1 1 1
Cerf, Dalal & Sunshine [Page 24] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[24ページ]RFC675仕様
The scenario for a simultaneous attempt to establish the connection without the arrival of any delayed duplicates is --
どんな遅れた写しの到着なしでも接続を確立する同時の試みのためのシナリオはそうです--
A B
------------ ------------
S1 S2 R S1 S2 R
B------------ ------------ S1 S2R S1 S2R
0 0 0 0 0 0
0 0 0 0 0 0
(M1) 1 0 0 --> <SEQ x><SYN> ...
(M1)1 0 0--><SEQ x><SYN>…
(M2) 0 0 0 <-- <SEQ y><SYN) <-- 1 0 0
(M2) 0 0 0<--<SEQ y><SYN) <-- 1 0 0
(M1) B returns no SYN sent --> 0 0 0
どんなSYNも送らなかった(M1)Bリターン-->0 0 0
(M1) 1 0 0 --> <SEQ z><SYN> * --> 0 0 1
(M1)1 0 0--><SEQ z><SYN>*-->0 0 1
(M3) 1 1 1 <-- <SEQ y+1><SYN,ACK z+1> <-- 1 0 1
(M3)1 1 1<--<SEQ y+1><SYN、ACK z+1><--1 0 1
(M4) 1 1 1 --> <SEQ z+1><ACK y+1><DATA> --> 1 1 1
(M4)1 1 1--><SEQ z+1><ACK y+1><データ>-->1 1 1
Note: "..." means that a message does not arrive, but is delayed
in the network. State changes are upon arrival or upon departure
of a given message, as the case may be. Packets containing the SYN
or INT or DSN bits implicitly contain a "dummy" data octet which
is never delivered to the user, but which causes the packet
sequence numbers to be incremented by 1 even if no real data is
sent. This permits the acknowledgment of these controls without
acknowledging receipt of any data which might also have been
carried in the packet. A packet containing a FIN bit has a dummy
octet following the last octet of data (if any) in the packet.
以下に注意してください。 「」 …は、メッセージが到着しないことを意味しますが、ネットワークで遅れます。 到着か場合によって与えられたメッセージの出発には州の変化があります。 それとなくSYN、INTまたはDSNビットを含むパケットがユーザに決して渡されませんが、どんな本当のデータも送らないでもパケット一連番号を1つ増加する「ダミー」のデータ八重奏を含んでいます。 また、パケットで運ばれたどんなデータの領収書も受け取ったことを知らせないで、これはこれらのコントロールの承認を可能にします。 パケットにおける、データ(もしあれば)の最後の八重奏に続いて、FINビットを含むパケットはダミーの八重奏を持っています。
* Once in state 000 sender selects new ISN z when attempting to
establish the connection again.
* 再び接続を確立するのを試みるとき、状態の一度、000送付者は新しいISN zを選択します。
4.3.3 HALF-OPEN CONNECTIONS
4.3.3 半開きな接続
An established connection is said to be a "half-open" connection if one of the TCP's has closed the connection at its end without the knowledge of the other, or if the two ends of the connection have become desynchronized owing to a crash that resulted in loss of memory. Such connections will automatically become reset if an attempt is made to send data in either direction. However, half-open connections are expected to be unusual, and the recovery procedure is somewhat involved.
確立した接続は「半開きな」接続がTCPの1つであるならもう片方に関する知識なしで接続を終わりに終えたか、または接続の2つの終わりがクラッシュで反連動するようになったならそれが記憶喪失をもたらしたということであると言われています。 どちらかの指示のデータを送るのを試みをするなら、そのような接続は自動的にリセットになるでしょう。 しかしながら、半開きな接続が珍しいと予想されて、リカバリ手順はいくらかかかわります。
Cerf, Dalal & Sunshine [Page 25] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[25ページ]RFC675仕様
If one end of the connection no longer exists, then any attempt by the other user to send any data on it will result in the sender receiving the event code "Connection does not exist at foreign TCP". Such an error message should indicate to the user process that something is wrong and it is expected to CLOSE the connection.
接続の片端がもう存在していないなら、どんなデータもそれに送るもう片方のユーザによるどんな試みもイベントコードを受け取る送付者では「接続は外国TCPに存在していない」という結果を望んでいます。 そのようなエラーメッセージは、何か問題があって、それが接続のCLOSEに予想されるのをユーザ・プロセスに示すべきです。
Assume that two user processes A and B are communicating with one another when a crash occurs causing loss of memory to B's TCP. Depending on the operating system supporting B's TCP, it is likely that some error recovery mechanism exists. When the TCP is up again B is likely to start again from the beginning or from a recovery point. As a result B will probably try to OPEN the connection again or try to SEND on the connection it believes open. In the latter case 1t receives the error message "connection not open" from the local TCP. In an attempt to establish the connection B's TCP will send a packet containing SYN. A's TCP thinks that the connection is already established and so will respond with the error "unacceptable SYN (or SYN/ACK) arrived at foreign TCP". B's TCP knows that this refers to the SYN it just sent out, and so should reset the connection and inform the user process of this fact.
2つのユーザ・プロセスAとBがクラッシュがいつビーズTCPに記憶喪失を引き起こしながら起こるかを伝えることであるとお互いと仮定してください。 ビーズTCPを支持するオペレーティングシステムによって、何らかのエラー回復メカニズムが存在しそうです。 TCPが再びBにいつかが始めか回復ポイントから再開しそうです。 その結果、Bは、たぶん再びオープンとして接続を裁くか、またはそれが開くと信じている接続のときにSENDに試みるでしょう。 後者では、ケース1tは地方のTCPから「オープンでない接続」というエラーメッセージを受け取ります。 接続ビーズを設立する試みでは、TCPはSYNを含むパケットを送るでしょう。 AのTCPは、接続が既に設立されるので誤りで応じると思います。「容認できないSYN(SYN/ACK)は外国TCPに到着しました」。 ビーズTCPは、これがそれがただ出したSYNを示して、接続をリセットするのでこの事実のユーザ・プロセスを知らせるべきであるのを知っています。
It may happen that B is passive and only wants to receive data. In this case A's data will not reach B because the TCP at B thinks the connection is not established. As a result A'S TCP will timeout and send a QRY to B's TCP. B's TCP will send STATUS saying the connection is not synched. A's TCP will treat this as if an implicit CLOSE had occurred and tell the user process, A, that the connection is closing. A is expected to respond with a CLOSE command to his TCP. However, A's TCP does not send a FIN to B's TCP, since it would not be accepted anyway on the unsynced connection. Eventually A will try to reopen the connection or B will give up and CLOSE. If B CLOSES, B's TCP will simply delete the connection since it was not established as far as B's TCP is concerned. No message will be sent to A'S TCP as a result.
Bが受け身であり、データを受け取るだけでありたいのは起こるかもしれません。 BのTCPが、接続が確立されないと思うので、この場合、AのデータはBに達しないでしょう。 その結果、AのTCPはビーズTCPにタイムアウトを望んでいて、QRYを送ります。 ビーズTCPはSTATUSに接続がsynchedされないと言わせるでしょう。 AのTCPは、まるで内在しているCLOSEが起こったかのようにこれを扱って、接続が閉じているとユーザ・プロセス、Aに言うでしょう。 AがCLOSEコマンドで彼のTCPに応じると予想されます。 しかしながら、AのTCPはビーズTCPにFINを送りません、それが非同期接続のときにとにかく受け入れられないでしょう、したがって。 結局、Aが接続を再開させようとするでしょうか、またはBは上とCLOSEに与えるでしょう。 B CLOSESであるなら、ビーズTCPに関する限り、それが設立されなかったので、ビーズTCPは単に接続を削除するでしょう。 その結果、AのTCPにメッセージを全く送らないでしょう。
4.3.4 RESYNCHRONIZING A CONNECTION
4.3.4 RESYNCHRONIZINGは接続です。
Details of resynchronization have not yet been specified since the need for this should be infrequent in the initial testing stages.
この必要性が初期の試験段階で珍しいはずであるので、再同期の細部はまだ指定されていません。
4.3.5 CLOSING A CONNECTION
4.3.5 接続を終えること。
There are essentially three cases:
本質的には、3つのケースがあります:
a) The user initiates by telling the TCP to CLOSE the connection
a) ユーザは、TCPに言うことによって、CLOSEに接続を開始します。
b) The remote TCP initiates by sending a FIN control signal
b) FIN制御信号を送るのによるリモートTCP開始
Cerf, Dalal & Sunshine [Page 26] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[26ページ]RFC675仕様
c) Both users CLOSE simultaneously
c) 同時の両方のユーザCLOSE
Two bits are used to maintain control over the closing of a connection: these are called the "FIN sent" bit [F] and the "USER Closed" bit, [C] respectively. The control procedure uses these two bits to assure that the connection is properly closed.
2ビットは接続の閉鎖のコントロールを維持するのに使用されます: これらは「FINは発信した」噛み付かれた[F]と「ユーザは閉じた」と[C] それぞれ噛み付かれた呼ばれます。 コントロール手順は、接続が適切に閉店することを保証するのにこれらの2ビットを使用します。
Case 1: Local user initiates the close
ケース1: 地元のユーザは閉鎖を開始します。
In this case, both the F and C bits are initially zero, but the C
bit is set immediately upon receipt of the user call "CLOSE." When
the FIN is sent out by the TCP, the F bit is set. All pending
RECEIVES are terminated and the user is told that they have been
prematurely terminated ("connection closing"} without data.
Similarly, any pending SENDS are terminated with the same
response, "connection closing."
この場合、ゼロ、Cビットだけがすぐに初めは設定されるというFとCビットの両方によることです。ユーザを受け取り次第、「近いところで」電話をしてください。 FINがTCPによって出されるとき、Fビットは設定されます。 すべての未定のRECEIVESが終えられて、ユーザが彼らが早まって終えられたと言われる、(「接続閉鎖」、データ同様に、どんな未定のSENDSも同じ応答で終えられます、「接続は閉じ」て。
Several responses may arrive as the result of sending a FIN. The
one which is generally expected is a matching FIN. When this is
received, the TCB CAN BE ELIMINATED. If a "connection does not
exist at foreign TCP" message comes in response to the FIN, then
the TCB can likewise be eliminated. If no response is forthcoming,
or if "Foreign TCP inaccessible" arrives then the resolution is
moot. One might simply timeout and discard the TCB. Since the
local user wants to CLOSE anyway, this is probably satisfactory,
although it will leave a potential "half-open" connection at the
other side. We deal with half open connections in section 4.3.3.
いくつかの応答がFINを送るという結果として到着するかもしれません。 一般に、期待されるのは合っているFINです。 これが受け取られているとき、TCB CAN BE ELIMINATEDです。 「接続は外国TCPに存在していない」メッセージがFINに対応して来るなら、同様にTCBを排除できます。 どんな応答も用意されていないか、または「近づきがたい外国TCP」が到着するなら、解決は論争中です。 そして、1が単にそうするかもしれない、タイムアウト、TCBを捨ててください。 CLOSEへの地方のユーザ必需品以来、とにかく、これはたぶん満足できます、反対側に潜在的「半開きな」接続を残すでしょうが。 私たちはセクション4.3.3における半分のオープンな接続に対処します。
When the acknowledging FIN arrives after the connection state bits
are set (F=1, C=1), then the TCB can be deleted.
接続州のビットが設定された(Fは1、C=1と等しいです)後に承認しているFINが到着すると、TCBを削除できます。
Case 2: TCP receives a FIN from the network
ケース2: TCPはネットワークからFINを受けます。
First of all, a FIN must have a sequence number which lies in the
valid receive window. If not, it is discarded and the left window
edge is sent as acknowledgment. If the FIN can be processed, it is
handled (possibly out of order, since it is taken as an imperative
to shut down the connection). All pending RECEIVES and SENDS are
responded to by showing that they were terminated by the other
side's close request (i.e. "connection closing"). The user is also
told by an unsolicited event or signal that the connection has
been closed (in some systems, the user might have to request
STATUS to get this information). Finally, the TCP sends FIN in
response.
まず、FINは有効にある一連番号に窓を受けさせなければなりません。 そうでなければ、それは捨てます、そして、承認として左の窓の優勢を送ります。 FINを処理できるなら、それは扱われます(ことによると故障しています、それが閉じるために命令としてみなされるので、接続より倒してください)。 すべての未定のRECEIVESとSENDSは、彼らが反対側の閉鎖によって終えられたのを示すことによって(すなわち、「接続閉鎖」)を要求するために反応します。 また、接続が閉店したという(いくつかのシステムで、ユーザは、この情報を得るようSTATUSに要求しなければならないかもしれません)求められていない出来事か信号によってユーザは言われます。 最終的に、TCPは応答でFINを送ります。
Thus, because a FIN arrived, a FIN is sent back, so the F bit is
set. However, the TCB stays around until the local user does a
CLOSE in acknowledgment of the unsolicited signal that the
したがって、FINが到着したのでFINが返送されるので、Fビットは設定されます。 しかしながら、地元のユーザが求められていなさの承認でCLOSEをするまで、TCBおよそ滞在はそれを示します。
Cerf, Dalal & Sunshine [Page 27] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[27ページ]RFC675仕様
connection has been closed by the other side. Thus, the C bit
remains unset until this happens. If the C and F bits go from (F=1
C=O) to (F=l, C=1), then the connection is closed and the TCB can
be removed.
接続は反対側によって閉店させられました。 したがって、これが起こるまで、Cビットはunsetのままで残っています。 CとFビットが(1F=C=O)から(F=l、C=1)まで行くなら、接続は閉じます、そして、TCBを取り外すことができます。
Case 3: both users close simultaneously
ケース3: 両方のユーザは同時に、閉じます。
If this happens, both connections will be in the (F=1, C=1) state.
When the FINs arrive, the connections w11i be shut down. If one
FIN fails to arrive, we have two choices. One is to insist on
acknowledgments for FINs, in which case the missing one will be
retransmitted. Another is merely to permit the half-open
connection to remain (we prefer this solution}. It can timeout
independently and go away after a while. If an attempt is made to
reestablish the connection, the initiator will discover the
existence of the open connection since an "inappropriate SYN
received" message will be sent by the TCP which holds the "half-
open" connection. The receiver of this message can tell the other
TCP to reset the connection. We cannot permit the holder of the
half-open connection to reset automatically on receipt of the SYN
since its receipt is not necessarily prima facie evidence of a
half open connection. (The SYN could be a delayed duplicate.)
これが起こると、両方の接続が(Fは1、C=1と等しいです)状態にあるでしょう。 FINsは到着して、接続はw11iです。いつ、閉鎖になってくださいか。 1FINが到着しないなら、私たちには、2つの選択があります。 人は、1が再送されるとその場合、FINsのための承認、取り逃がすことを主張することになっています。 しばらくして、遠ざかってください。そして、別のものが、半開きな接続が残っているのを単に許容することになっている、(私たちがこの解決策を好む、そうすることができる、タイムアウト、独自である、接続を回復させるのを試みをすると、「不適当なSYNは受信した」というメッセージが「半分開いている」接続を保持するTCPによって送られるので、創始者はオープンな接続の存在を発見するでしょう; このメッセージの受信機は、接続をリセットするようにもう片方のTCPに言うことができます。私たちは、領収書が必ず一見したところでは半分のオープンな接続に関する証拠でないので、SYNを受け取り次第自動的にリセットする半開きな接続の所有者を許可できません。(SYNは遅れた写しであるかもしれません。)
4.3.6. CONNECTION STATE and its relation to USER and INCOMING CONTROL REQUESTS
4.3.6. USERとINCOMING CONTROL REQUESTSとのCONNECTION STATEとその関係
In order to formalize the action taken by the TCP when it receives commands from the User, or Control information from the network, we define a connection to be in one of 7 states at any instant. These are known as the TCB Major States. Each Major State is simply a convenient name for a particular setting or group of settings of the state bits, as follows:
Userからコマンドを受け取るときTCPによって取られた行動を正式にするか、またはネットワークからControl情報を正式にして、私たちは、どんな瞬間にも、7つの州の1つにいるように接続を定義します。 これらはTCBメージャーStatesとして知られています。 それぞれのメージャー州は単に州のビットの設定の特定の設定かグループに、便利な名前です、以下の通りです:
S1 S2 R U F C # name
S1 S2R U F C#名
- - - - - - 0 no TCB
- - - - - - 0 TCBがありません。
0 0 0 0/1 0 0 1 unsync
0 0 0 0/1 0 0 1の「非-同時性」
1 0 0 0 0 0 2 SYN sent
1 0 0 0 0 0 2SYNは発信しました。
1 0 1 0/1 0 0 3 SYN received
1 0 1 0/1 0 0 3SYNは受信しました。
1 1 1 0 0 0 4 established
確立された1 1 1 0 0 0 4
1 0/1 1 0/1 1 1 5 FIN wait
1 0/1 1 0/1 1 1 5FINは待っています。
1 1 1 0 1 0 6 FIN received
1 1 1 0 1 0 6FINは受信しました。
Cerf, Dalal & Sunshine [Page 28] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[28ページ]RFC675仕様
The connection moves from state to state as shown below. The transition from one state to another will be represented as
接続は以下に示すように述べる状態から移ります。 別のものへの状態が表される1からの変遷
[X, Y]<cause><action>
[X、Y] <原因><動作>。
which means that there is a transition from state X to state Y owing to <cause>. The action taken by the TCP is specified as <action>. We use this notation to give the important state transitions, often simplifying the cause and action fields to take into account a number of situations. Figure 1 illustrates these transitions in traditional state diagram form. Section 4.4.6 and section 4.4.7 fully specify the effect of all User commands and Control information arriving from the network.
<原因>のためにYを述べるために状態Xからの変遷があることを意味します。 TCPによって取られた行動は<動作>として指定されます。 私たちは重要な状態遷移を与えるのにこの記法を使用します、多くの状況を考慮に入れるためにしばしば原因と動作分野を簡素化して。 図1は伝統的な州のダイヤグラムのフォルムでこれらの変遷を例証します。 セクション4.4.6とセクション4.4.7はすべてのUserコマンドとネットワークから到着するControl情報の効果を完全に指定します。
[0,l] <OPEN> <create TCB>
[0、l] <戸外の><はTCB>を作成します。
[1,2] <SEND,INTERRUPT, or collision timeout> <send SYN>
[1、2] <SEND、INTERRUPT、または衝突タイムアウト><がSYN>を送ります。
[1,3] <SYN arrives> <send SYN,ACK>
[1、3]<SYNは到着します。><がSYNを送る、ACK>。
[1,0] <CLOSE> <remove TCB>
[1、0] <閉鎖><はTCB>を取り外します。
[2,1] <SYN arrives (collision)> <set timeout, forget SYNs>
[2、1]<SYNは到着します。(衝突)><がタイムアウトを設定する、SYNs>を忘れてください。
[2,0] <CLOSE> <remove TCB>
[2、0] <閉鎖><はTCB>を取り外します。
[2,4] <appropriate SYN,ACK arrives> <send ACK>
[2、4]<の適切なSYN、ACKが到着する、><はACK>を送ります。
[3,4] <appropriate ACK arrives> <none>
[3、4]<の適切なACKが到着する、><、>のいずれも
[3,1] <error arrives or timeout> <(forget SYN)>
[3、1]<誤りが到着する、タイムアウト><。(SYNを忘れます)>。
[3,5] <CLOSE> <send FIN>
[3、5] <閉鎖><はフィン>を送ります。
[4,5] <CLOSE> <send FIN>
[4、5] <閉鎖><はフィン>を送ります。
[4,6] <appropriate FIN arrives> <send FIN, inform user>
[4、6]<適切なFINは到着します。><がFINを送る、ユーザ>に知らせてください。
[5,0] <FIN or error arrives, or timeout> <remove TCB>
[5、0] <FINか誤りが届くか、またはタイムアウト><はTCB>を取り外します。
[6,0] <CLOSE> <remove TCB>
[6、0] <閉鎖><はTCB>を取り外します。
4.4 STRUCTURE 0F THE TCP
4.4 構造0F TCP
4.4.l INTRODUCTION [See figure 2.1]
4.4. l序論[2.1が計算するのがわかります]
There are many possible implementations of the TCP. We offer one conceptual framework in which to view the various algorithms that
TCPの多くの可能な実現があります。 私たちは様々なアルゴリズムを見る1つの概念の構成にそれを提供します。
Cerf, Dalal & Sunshine [Page 29] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[29ページ]RFC675仕様
make up the TCP design. In our concept, the TCP is written in two parts, an interrupt or signal driven part (consisting of four processes), and a reentrant library of subroutines or system calls which interface the user process to the TCP. The subroutines communicate with the interrupt part through shared data structures (TCB's, shared buffer queues etc.). The four processes are the Output Packet Handler which sends packets to the packet switch; the Packetizer which formats letters into internet packets; the Input Packet Handler which processes incoming packets; and the Reassembler which builds letters for users.
TCPデザインを作ってください。 私たちの概念では、TCPは2つの部品、中断に書くか、またはやる気満々の部分に合図すること(4つの過程から成って)であり、リエントラントはTCPにユーザ・プロセスを連結するサブルーチンかシステムコールのライブラリです。 サブルーチンは共有データ構造(共有バッファ待ち行列TCBなど)を通して中断部分とコミュニケートします。 4つの過程がパケットをパケット交換機に送るOutput Packet Handlerです。 インターネットパケットに手紙をフォーマットするPacketizer。 入って来るパケットを処理するInput Packet Handler。 そして、ユーザのために手紙を造るReassembler。
The ultimate bottleneck is the pipe through which arriving and departing packets must travel. This is the Host/Packet Switch interface. The interrupt driven TCP shares among all TCB's its limited packet buffer resources for sending and receiving packets. From the standpoint of controlling buffer congestion, it appears better to TREAT INCOMING PACKETS WITH HIGHER PRIORITY THAN OUTGOING PACKETS. That is, packet buffers which can be released by copying their contents into user buffers clearly help to reduce congestion. Neither the packetizer nor the input packet handler should be allowed to take up all available packet buffer space; an analogous problem arises in the IMP in the allocation of store and forward, and reassembly buffer space. One policy is to permit neither contender more than, say, two-thirds of the space. The buffer allocation routines can enforce these limits and reject buffer requests as needed. Conceptually, the scheduler can monitor the amounts of storage dedicated to the input and output routines, and can force either to sleep if its buffer allocation exceeds the limit.
究極のボトルネックは到着して、パケットを去るのが旅行しなければならないパイプです。 これはHost/パケットSwitchインタフェースです。 中断の駆動TCPはTCBのすべてのところで送受信パケットのための限られたパケットバッファ資源を共有します。 制御の見地から、混雑をバッファリングしてください、そして、それはTREAT INCOMING PACKETS WITH HIGHER PRIORITY THAN OUTGOING PACKETSにより良く見えます。 すなわち、明確にユーザバッファの中にそれらのコンテンツをコピーすることによって発表できるパケットバッファは、混雑を抑えるのを助けます。 packetizerも入力パケット操作者もすべての利用可能なパケットバッファ領域を取ることができるべきであるというわけではありません。 類似の問題はIMPに店と前進の、そして、再アセンブリなバッファ領域の配分で起こります。 ある方針はたとえば、スペースの2/3ほどどちらの競争者も可能にしないことです。 バッファ割り当てルーチンは、これらの限界を実施して、必要に応じてバッファ要求を拒絶できます。 概念的に、スケジューラによって入出力ルーチンに捧げられた格納の量をモニターできて、バッファ配分が度を超すなら、どちらかがやむを得ず眠ることができます。
As an example, we can consider what happens when a user executes a SEND call to the TCP service routines. The buffer containing the letter is placed on a SEND buffer queue associated with the user's TCB. A 'packetizer' process is awakened to look through all the TCB's for 'packetizing' work. The packetizer will keep a roving pointer through the TCB list which enables it to pick up new buffers from the TCB queue and packetize them into output buffers. The packetizer takes no more than one letter at a time from any single TCB. The packetizer attempts to maintain a non-empty queue of output packets so that the output handler will not fall idle waiting for the packetizing operation. However, since arriving packets compete with departing packets, care must be taken to prevent either class from occupying all of the shared packet buffer space. Similarly since the TCB's all compete for space in service to their connections, neither input nor output packet space should be dominated by any one TCB.
例として、私たちは、ユーザがTCPサービス・ルーチンにSEND呼び出しを実行するとき、何が起こるかを考えることができます。 手紙を入れてあるバッファはユーザのTCBに関連しているSENDバッファ待ち行列に置かれます。 'packetizer'の過程は、仕事が'packetizingする'であるためにTCBのすべてのものに目を通すために目を覚まします。 packetizerはTCB待ち行列から新しいバッファを受信して、出力バッファの中にそれらをpacketizeするのを可能にするTCBリストを通して流浪ポインタを保つでしょう。 packetizerはどんな独身のTCBからの一度に1つ未満の文字も取ります。 出力操作者が転ばないように出力パケットの非空の待ち行列を維持するpacketizer試みは、packetizing操作を待ちながら、怠けます。 しかしながら、到着パケットがパケットを去るのと競争するので、どちらのクラスも共有されたパケットバッファ領域のすべてを占領するのを防ぐために注意しなければなりません。 同様に、TCBのもの以来、すべてが彼らの接続に、使用中のスペースを競争して、どんなTCBも入力も出力パケットスペースも支配するはずがありません。
When a packet is created, it is placed on a FIFO SEND packet queue associated with its origin TCB. The packetizer wakes the output handler and then continues to packetize a few more buffers, perhaps,
パケットが作成されるとき、それは起源TCBに関連しているFIFO SENDパケット待ち行列に置かれます。 packetizerは、出力操作者を起こして、次に、恐らくバッファをもう少しpacketizeし続けています。
Cerf, Dalal & Sunshine [Page 30] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[30ページ]RFC675仕様
before going to sleep. The output handler is awakened either by a 'hungry' packet switch or by the packetizer; in either case, it uses a roving TCB pointer to select the next TCB for service. The send packet queue can be used as a 'work queue' for the output handler. After a packet has been sent, but usually before an ACK is returned, the output handler moves the packet to a retransmission queue associated with each TCB.
寝つく前に。 出力操作者は'空腹な'パケット交換機かpacketizerによって目を覚まします。 どちらの場合ではも、それは、サービスのために次のTCBを選択するのに流浪しているTCBポインタを使用します。 出力操作者のために'仕事待ち行列'を待ち行列を使用できるパケットに送ってください。 通常、ACKを返す前を除いて、パケットを送った後に、出力操作者はパケットを各TCBに関連している再送キューに動かします。
Retransmission timeouts can refer to specific packets and the retransmission list can be searched for the specific packet. If an ACK is received, the retransmission entry can be removed from the retransmit queue. The send packet queue contains only packets waiting to be sent for the first time. INTERRUPT requests can remove entries in both the send packet queue and the retransmit packet queue.
再送タイムアウトは特定のパケットについて言及できます、そして、「再-トランスミッション」リストは特定のパケットを捜すことができます。 ACKが受け取られているなら、再送キューから「再-トランスミッション」エントリーを取り除くことができます。 初めて送られるのを待つパケットだけを待ち行列が含むパケットに送ってください。 そして、INTERRUPT要求が両方でエントリーを取り除くことができる、パケット待ち行列を送ってください、パケット待ち行列を再送してください。
Since packets are never in more than one queue at a time, it appears possible for INT, FIN or RESET commands to remove packets from the receive, send, or retransmit packet queues with the assurance that an already issued signal to enter the reassembler, the packetizer or the output handler will not be confusing.
パケットが一度に1つ以上の待ち行列決して中でないのでパケットを取り除くINT、FINまたはRESETコマンドに可能に見える、受信するか、発信するか、または「再-アセンブラ」、packetizerまたは出力操作者に入る既に発行された信号が混乱させられないという保証でパケット待ち行列を再送してください。
Handling the INTERRUPT and CLOSE functions can however require some care to avoid confusing the scheduler, and the various processes. The scheduler must maintain status information for the processes. This information includes the current TCB being serviced. When an INTERRUPT is issued by a local process, the output queue of letters associated with the local port reference is to be deleted. The packetizer, for example, may however be working at that time on the same queue. As usual, simultaneous reading and writing of the TCB queue pointers must be inhibited through some sort of semaphore or lockout mechanism. When the packetizer wants to serve the next send buffer queue, it must lock out all other access to the queue, remove the head of the queue (assuming of course that there are enough buffers for packetization), advance the head of the queue, and then unlock access to the queue.
しかしながら、INTERRUPTとCLOSE機能を扱うのは、スケジューラ、および様々な過程を混乱させるのを避けるために何らかの注意を必要とすることができます。 スケジューラは過程のための状態情報を保守しなければなりません。 この情報は調整される現在のTCBを含んでいます。 INTERRUPTがローカルの工程で発行されるとき、ローカルのポート参照に関連している手紙の出力キューは削除されることです。 しかしながら、例えば、packetizerはその時、同じ待ち行列に取り組んでいる予定であるかもしれません。 いつものように、ある種の腕木信号機かロックアウトメカニズムを通して同時の読書とTCB待ち行列ポインタを主題にして書くのを禁止しなければなりません。 次に役立つpacketizer必需品がバッファ待ち行列を送ると、それは、待ち行列への他のすべてのアクセスを締め出して、待ち行列(もちろん、packetizationのためのバッファが十分あると仮定する)のヘッドを外して、待ち行列のヘッドを進めて、待ち行列へのアクセスをアンロックしなければなりません。
If the packetizer keeps only a TCB pointer in a global place called CPTCB (current packetizer TCB address), and always uses the address in CPTCB to find the TCB in which to examine the send buffer queue, then removal of the output buffer queue does not require changes to any working storage belonging to the packetizer. Even more important, the arrival and processing of a RESET or CLOSE, which clears the system of a given TCB, can update the CPTCB pointer, as long as the removal does not occur while the packetizer is still working on the TCB.
packetizerがCPTCB(現在のpacketizer TCBアドレス)と呼ばれるグローバルな場所にTCBポインタだけを保って、中でTCBを見つけるのにCPTCBでいつもアドレスを使用する、どれを調べるか、バッファ待ち行列を送ってください、と出力バッファ待ち行列の当時の取り外しは変化をpacketizerに属すどんな働く格納にも必要としません。 さらに重要です、与えられたTCBをシステムから取り除くRESETかCLOSEの到着と処理はCPTCBポインタをアップデートできます、packetizerがまだTCBに取り組んでいる間、取り外しが起こらない限り。
Cerf, Dalal & Sunshine [Page 31] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[31ページ]RFC675仕様
Incoming packets are examined by the input packet handler. Here they are checked for valid connection sockets, and acknowledgments are processed, causing packets to be removed, possibly, from the SEND or RETRANSMIT packet queues as needed. As an example, consider the receipt of a valid FIN request on a particular TCB. If a FIN had not been sent before (i.e. F bit not set), then a FIN packet is constructed and sent after having cleared out the SEND buffer and SEND packet queues as well as the RETRANSMIT queue. Otherwise, if the F and C bits are both set, all queues are emptied and the TCB is returned to free storage.
入って来るパケットは入力パケット操作者によって調べられます。 ここで、それらは有効な接続ソケットがないかどうかチェックされます、そして、承認は処理されます、パケットがことによると必要に応じてSENDかRETRANSMITパケット待ち行列から取り除かれることを引き起こして。 例と、特定のTCBに関する有効なFIN要求の領収書を考えてください。 以前FINを送ったことがなかったなら(すなわち、Fビットはセットしませんでした)、RETRANSMIT待ち行列と同様にSENDバッファとSENDパケット待ち行列を取り除いた後に、FINパケットを組み立てて、送ります。 さもなければ、ともにFとCビットを設定するなら、すべての待ち行列を空にします、そして、格納を解放するためにTCBを返します。
Packets which should be reassembled into letters and sent to users are queued by the input packet handler, on the receive packet queue, for processing by the reassembly process. The reassembler looks at its FIFO work queue and tries to move packets into user buffers which are queued up in an input buffer queue on each TCB. If a packet has arrived out of order, it can be queued for processing in the correct sequence. Each time a packet is moved into a user buffer, the left window edge of the receiving TCB is moved to the right so that outgoing packets can carry the correct ACK information. If the SEND buffer queue is empty, then the reassembler creates a packet to carry the ACK.
手紙に組み立て直されて、ユーザに送られるべきであるパケットは入力パケット操作者によって列に並ばせられます、オンである、パケット待ち行列を受けてください、再アセンブリする工程による処理のために。 「再-アセンブラ」は、先入れ先出し法仕事が列を作るのを見て、パケットを各TCBに入力バッファ待ち行列で列を作られるユーザバッファの中に動かそうとします。 パケットが故障していた状態で到着したなら、正しい系列における処理のためにそれを列に並ばせることができます。 パケットがユーザバッファの中に動かされる各回、受信TCBの左の窓の縁は、出発しているパケットが正しいACK情報を運ぶことができるように、右に動かされます。 SENDバッファ待ち行列が空であるなら、「再-アセンブラ」は、ACKを運ぶためにパケットを作成します。
As packets are moved 1nto buffers and they are filled, the buffers are dequeued from the RECEIVE buffer queue and passed to the user. The reassembler can also be awakened by the RECEIVE user call should it have a non-empty receive packet queue with an empty RECEIVE buffer queue. The awakened reassembler goes to work on each TCB, keeping a roving pointer, and sleeping if a cycle is made of all TCB's without finding any work.
パケットが動く1ntoバッファであり、それらがいっぱいにされるとき、バッファは、RECEIVEバッファ待ち行列からデキューされて、ユーザに渡されます。 「再-アセンブラ」はそうすることができます、また、目を覚ましてください。aを非空にするならユーザが呼ぶRECEIVEは空のRECEIVEバッファ待ち行列でパケット待ち行列を受けます。 流浪ポインタを保って、1サイクルがどんな仕事も見つけないでTCBのすべてのもので作られるなら眠って、目を覚ました「再-アセンブラ」は各TCBに働きかけます。
4.4.2 INPUT PACKET HANDLER [See figure 2.2]
4.4.2 入力パケット操作者[2.2が計算するのがわかります]
The Input Packet Handler is awakened when a packet arrives from the network. It first verifies that the packet is for an existing TCB (i.e. the local and foreign socket numbers are matched with those of existing TCB's). If this fails, an error message is constructed and queued on the send packet queue of a dummy TCB. A signal is also sent to the output packet handler. Generally, things to be transmitted from the dummy TCB have a default retransmission timeout of zero, and will not be retransmitted. (We use the idea of a dummy TCB so that all packets containing errors, or RESET can be sent by the output packet handler, instead of having the originator of them interface to the net. These packets, it will be noticed, do not belong to any TCB).
パケットがネットワークから到着すると、Input Packet Handlerは目を覚まします。 それは、最初に、パケットが既存のTCBのためのものであることを確かめます(すなわち、地方の、そして、外国のソケット番号は既存のTCBのもののものに合わせられています)。 これが失敗するなら、エラーメッセージに組み立てられて、列を作られる、ダミーのTCBのパケット待ち行列を送ってください。 また、出力パケット操作者に信号を送ります。 一般に、ダミーのTCBから伝えられることは、ゼロのデフォルト再送タイムアウトを持って、再送されないでしょう。 (私たちがダミーのTCBの考えを使用するので、誤りを含むすべてのパケット、またはRESET缶がそれらの創始者がいることの代わりに出力パケット操作者によって送られるのはネットに連結します。 それはこれらのパケットがどんなTCBにも属さないのに気付かれるでしょう。).
Cerf, Dalal & Sunshine [Page 32] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[32ページ]RFC675仕様
The input packet handler looks out for control or error information and acts appropriately. Section 4.4.7 discusses this in greater detail, but as an example, if the incoming packet is a RESET request of any kind (i.e. all connections from designated TCP or given connection), and is believable, then the input packet handler clears out the related TCB(s), empties the send and receive packet queues, and prepares error returns for outstanding user SEND(s) and RECEIVE(s) on each reset TCB. The TCB's are marked unused and returned to storage. If the RESET refers to an unknown connection, it is ignored.
入力パケット操作者は、コントロールかエラー情報を探して、ふさわしい行動を取ります。 セクション4.4.7が詳細によりすばらしいこれについて議論しますが、入って来るパケットがどんな種類(指定されたTCPか当然のことの接続からのすなわちすべての接続)のRESET要求でありも、信用できるなら、入力パケット操作者が例として、関連するTCB(s)を取り除いて、空になる、それぞれのリセットTCBの上の傑出しているユーザSEND(s)とRECEIVE(s)のためにパケット待ち行列を送って、受けて、誤りリターンを準備します。 TCBのものを未使用であるとマークして、格納に返します。 RESETが未知の接続について言及するなら、それは無視されます。
Any ACK's contained in incoming packets are used to update the send left window edge, and to remove the ACK'ed packets from the TCB retransmit packet queue. If the packet being removed was the end of a user buffer, then the buffer must be dequeued from the packetized buffer queue, and the User informed. The packetizer is also signaled. Only one signal, or one for each packet, will have to be sent, depending on the scheduling scheme for the processes. See section 4.4.7 for a detailed discussion.
含まれたACKのどんなものも入って来るパケットでアップデートに使用される、左の窓の優勢を送ってください、そして、TCBからACK'edパケットを取り除くために、パケット待ち行列を再送してください。 取り除かれるパケットがユーザバッファの端であったなら、packetizedバッファ待ち行列からバッファをデキューしなければなりませんでした、そして、Userは知らせました。 また、packetizerは合図されます。 1つの信号、または各パケットあたり1つを送るだけでよいでしょう、過程のためにスケジューリング計画によって。 詳細な論議に関してセクション4.4.7を見てください。
The packet sequence number, the current receive window size, and the receive left window edge determine whether the packet lies within the window or outside of it.
そして、パケット一連番号、現在のレシーブ・ウィンドウ・サイズ、パケットが窓以内かそれの外にあるか否かに関係なく、縁が決定する左の窓を受けてください。
Let W = window size
Wをウィンドウサイズとの等しさにしてください。
S = size of sequence number space
Sは一連番号スペースのサイズと等しいです。
L = left window edge
Lは左の窓の縁と等しいです。
R = L+W-1 = right window edge
R=L+W-1は正しい窓の縁と等しいです。
x = sequence number to be tested
xは、テストされるために一連番号と等しいです。
For any sequence number, x, if
どんな一連番号、xのためにも
(R-x) mod S <= W
(R-x) モッズS<はWと等しいです。
then x is within the window.
そして、窓の中にxがあります。
A packet should be rejected only if all of it lies outside the window. This is easily tested by letting x be, first the packet sequence number, and then the sum of packet sequence number and packet text length, less one. If the packet lies outside the window, and there are no packets waiting to be sent, then the input packet handler should construct a dummy ACK and queue it for output on the
皆が窓の外に横たわる場合にだけ、パケットは拒絶されるべきです。 これは容易に最初に、xがあることによってパケット一連番号がテストされて、次に、パケット一連番号とパケットテキストの長さの合計、より少ない1をテストされます。 パケットがそこに窓の外にあるなら、出力には、送ります、次に、入力パケット操作者がaダミーのACKを組み立てるべきであるということであり、それを列に並ばせるのを待つどんなパケットも、オンではありません。
Cerf, Dalal & Sunshine [Page 33] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[33ページ]RFC675仕様
send packet queue, and signal the output packet handler. Successfully received packets are placed on the receive packet queue in the appropriate sequence order, and the reassembler signaled.
パケット待ち行列を送ってください、そして、出力パケット操作者に合図してください。 首尾よく受け取られたパケットが置かれる、適切な系列注文、および合図された「再-アセンブラ」でパケット待ち行列を受けてください。
The packet window check can not be made if the associated TCB is not in the 'established' state, so care must be taken to check for control and TCB state before doing the window check.
関連TCBが'確立した'状態にないならパケット・ウィンドウチェックをすることができないので、窓のチェックをする前にコントロールとTCB状態がないかどうかチェックするために注意しなければなりません。
4.4.3 REASSEMBLER [See figure 2.3]
4.4.3 REASSEMBLER[2.3が計算するのがわかります]
The Reassembler process is activated by both the Input Packet Handler and the RECEIVE user call. While the reassembler is asleep, if multiple signals arrive, all but one can be discarded. This is important as the reassembler does not know the source of the signal. This is so in order that "dangling" signals from work in TCB's that have subsequently been removed don't confuse it. Each signal simply means that there may be work to be done. If the reassembler is awake when a signal arrives, it may be necessary to put 1t in a "hyperawake" state so that even if the reassembler tries to quit, the scheduler will run it one more time.
Reassemblerの過程はInput Packet HandlerとRECEIVEユーザ呼び出しの両方で活性化します。 複数の信号が届くなら「再-アセンブラ」が眠っている間、ほとんど1つを捨てることができます。 「再-アセンブラ」が信号についてソースを知らないようにこれは重要です。 したがって、これは、次に取り外されたTCBのところでの仕事からの「中ぶらりん」の信号がそれを混乱させないそうです。 各信号は、やるべき仕事があるかもしれないことを単に意味します。 信号が届くとき、「再-アセンブラ」が目覚めるなら、「再-アセンブラ」がやめようとさえすると、スケジューラが、より多くの1回の間、それを走らせるように"hyperawake"のtが述べる1を置くのが必要であるかもしれません。
When the reassembler is awakened it looks at the receive packet queue for each TCB. If there are some packets there then it sees whether the RECEIVE buffer queue is empty. If it is then the reassembler gives up on this TCB and goes on to the next one, otherwise if the first packet matches the left window edge, then the packet can be moved into the User's buffer. The reassembler keeps transferring packets into the User's buffer until the letter is completely transferred, or something causes it to stop. Note that a buffer may be partly filled and then a sequence 'hole' is encountered in the receive packet queue. The reassembler must mark progress so that the buffer can be filled up starting at the right place when the 'hole' is filled. Similarly a packet might be only partially emptied when a buffer is filled, so progress in the packet must be marked.
いつ目を覚まされて、見るという「再-アセンブラ」によることであるか、各TCBのためにパケット待ち行列を受けてください。 いくつかのパケットがそこにあれば、それは、RECEIVEバッファ待ち行列が空であるかどうかわかります。 それがあるなら、「再-アセンブラ」は、このTCBに見切りをつけて、次のものに進んでいます。さもなければ、最初のパケットが左の窓の縁に合っているなら、パケットはUserのバッファの中に動かすことができます。 「再-アセンブラ」が手紙を完全に移すまでUserのバッファの中にパケットを移し続けるか、またはそれは何かで止まります。 バッファが一部いっぱいにされるかもしれないというメモと次に、系列'穴'が遭遇する、パケット待ち行列を受けてください。 「再-アセンブラ」は、'穴'がいっぱいにされるとき、適当な場所で始まって、バッファを満たすことができるように進歩をマークしなければなりません。 バッファがいっぱいにされるときだけ、同様に、パケットが部分的に空にされるかもしれないので、パケットでの進歩をマークしなければなりません。
If a letter was successfully transferred to a User buffer then the reassembler signals the User that a letter has arrived and dequeues the buffer associated with it from the TCB RECEIVE buffer queue. If the buffer is filled then the User is signaled and the buffer dequeued as before. The event code indicates whether the buffer contains all or part of a letter, as described in section 2.4.
首尾よくUserバッファに手紙を移したなら、「再-アセンブラ」は、手紙が届いたとUserに合図して、TCB RECEIVEバッファ待ち行列によってそれに関連しているバッファをデキューします。 バッファはいっぱいにされます、次に、Userが合図されるかどうか、そして、従来と同様デキューされたバッファ。 イベントコードは、バッファがセクション2.4で説明されるように手紙のすべてか一部を含むかどうかを示します。
In every case when a packet is delivered to a buffer, the receive left window edge is updated, and the packetizer is signaled. This updating must take account of the extra octet included in the sequencing for certain control functions [SYN, INT, FIN, DSN]. If the send packet queue is empty then the reassembler must create a packet to carry the ACK, and place it on the send packet queue.
受信してください。いつもパケットをバッファに届けるときの場合で合図する、残されて、窓の縁をアップデートして、packetizerに合図します。 このアップデートはあるコントロール機能[SYN、INT、FIN、DSN]のための配列に含まれていた余分な八重奏を考慮に入れなければなりません。 発信、パケット待ち行列が空であり、次に、「再-アセンブラ」がACKを運んで、それを置くパケットを作成しなければならない、パケット待ち行列を送ってください。
Cerf, Dalal & Sunshine [Page 34] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[34ページ]RFC675仕様
Note that the reassembler never works on a TCB for more than one User buffer's worth of time, in order to give all TCB's equal service.
「再-アセンブラ」が1つ以上のUserバッファの倍の価値のためにTCBに決して働かないことに注意してください、すべてのTCBの等しいサービスを与えるために。
Scheduling of the reassembler is a big issue, but perhaps running to completion will be satisfactory, or else it can be time sliced. In the latter case it will continue from where it left off, but a new signal may have arrived producing some possible work. This work will be processed as part of the old incomplete signal, and so some wasteful processing may occur when the reassembler wakes up again. This is the general problem of trying to implement a protocol that is fundamentally asynchronous, but at least it is immune to harmful race-conditions. E.g. if we were to have the reassembler 'remove' the signal that caused it to wake up, just before it went to sleep (in order that new arriving ones were discarded) then a new signal may arrive at a critical time causing 1t not to be recognized; thus leaving some work pending, and this may result in a deadlock [see previous comments on "hyperawake" state].
「再-アセンブラ」のスケジューリングは大問題ですが、恐らく完成に駆けつけるのは満足できるだろうか、切られて、時間であるかもしれません。 それがどこから続けている後者の場合では、やめましたが、新しい信号は、いくらかの可能な仕事を起こしながら、届いたかもしれません。 この仕事が古い不完全な信号の一部として処理されるので、「再-アセンブラ」が再び目覚めると、何らかの無駄な処理が起こるかもしれません。 これは基本的に非同期なプロトコルを実行しようとするという一般的問題ですが、少なくともそれは有害な競合条件に免疫があります。 例えば、私たちが、「再-アセンブラ」が寝つくすぐ前にそれが目覚めた信号を'取り除くこと'を持つつもりであったなら(新しい到着ものが捨てられたために)、新しい信号は認識されないように重要な時間引き起こす1tに届くかもしれません。 したがって、或るものは未定の状態で働いて、いなくなる、これは行き詰まりをもたらすかもしれません["hyperawake"状態で前のコメントを見てください]。
4.4.4 PACKETIZER [See figure 2.4]
4.4.4 PACKETIZER[2.4が計算するのがわかります]
The Packetizer process gets work from both the Input Packet Handler and the SEND user call. The signal from the SEND user call indicates that there is something new to send, while the one from the input packet handler indicates that more TCP buffers may be available from delivered packets. This latter signal is to prevent deadlocks in certain kind of scheduling schemes. We assume the same treatment of signals as discussed in section 4.4.3.
Packetizerの過程はInput Packet HandlerとSENDユーザ呼び出しの両方から仕事をもらいます。 SENDユーザ呼び出しからの信号は、何か送るもの新しいものがあるのを示します、入力パケット操作者からの人は、より多くのTCPバッファが渡されたパケットから利用可能であるかもしれないことを示しますが。 この後者の信号はある種類のスケジューリング計画における行き詰まりを防ぐことです。 私たちはセクション4.4.3で議論するように信号の同じ処理を仮定します。
When the packetizer is awakened it looks at the SEND buffer queue for each TCB. If there is a new or partial letter awaiting packetization, it tries to packetize the letter, TCB buffer and window permitting. It packetizes no more than one letter for a TCB before servicing another TCB. For every packet produced it signals the output packet handler (to prevent deadlock in a time sliced scheduling scheme). If a 'run till completion' scheme is used then one signal only need be produced, the first time a packet is produced since awakening. If packetization is not possible the packetizer goes on to the next TCB.
packetizerが目を覚ますとき、それは、SENDバッファが各TCBのために列を作るのを見ます。 packetizationを待つ新しいか部分的な手紙があれば、それは手紙、TCBバッファ、窓のおよび可能にすることをpacketizeしようとします。 別のTCBを調整する前に、それはTCBのための1つ未満の文字をpacketizesします。 作り出されたあらゆるパケットに関しては、それは出力パケット操作者(時間の切られたスケジューリング計画における行き詰まりを防ぐ)に合図します。 '完成までの走行'計画が使用されているなら、1つの信号だけが作り出されなければなりません、目を覚まして以来パケットが作り出される1回目。 packetizationが可能でないなら、packetizerは次のTCBに進んでいます。
If a partial buffer was transferred then the packetizer must mark progress in the SEND buffer queue. Completely packetized buffers are dequeued from the SEND buffer queue, and placed on a Packetized buffer queue, so that the buffer can be returned to the user when an ACK for the last bit is received.
部分的なバッファを移したなら、packetizerはSENDバッファ待ち行列における進歩をマークしなければなりません。 完全にpacketizedされたバッファは、SENDバッファ待ち行列からデキューされて、Packetizedバッファ待ち行列に置かれます、最後のビット単位でACKが受け取られているとき、バッファをユーザに返すことができるように。
When the packetizer packetizes a letter it must see whether it is the first piece of data being sent on the connection, in which case it must include the SYN bit. Some implementations may not permit data to be sent with SYN and others may discard any data received with SYN.
packetizer packetizesであるときに、それがその場合、接続、それで送られる最初の片のデータであるか否かに関係なく、見なければならない手紙はSYNビットを含まなければなりません。 いくつかの実現は、データがSYNと共に送られることを許可しないかもしれません、そして、他のものはSYNと共に受け取られたどんなデータも捨てるかもしれません。
Cerf, Dalal & Sunshine [Page 35] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[35ページ]RFC675仕様
The Packetizer goes to sleep if it finds no more work at any TCB.
どんなTCBでもそれ以上の仕事を全く見つけないなら、Packetizerは寝つきます。
4.4.5 OUTPUT PACKET HANDLER [see figure 2.5]
4.4.5 出力パケット操作者[2.5が計算するのがわかります]
When activated by the packetizer, or the input packet handler, or some of the user call routines, the Output Packet Handler attempts to transmit packets on the net (may involve going through some other network interface program). It looks at the TCB's in turn, transmitting some packets from the send packet queue. These are dequeued and put on the retransmit queue along with the time when they should be retransmitted.
packetizer、入力パケット操作者、またはユーザ呼び出しルーチンのいくつかで動かされると、Output Packet Handlerは、ネット(ある他のネットワーク・インターフェースプログラムを通ることを伴うかもしれない)でパケットを伝えるのを試みます。 それ、順番にTCBのものを見て、いくつかのパケットを伝える、パケット待ち行列を送ってください。 これらは、それらが再送されるべきである時に伴う再送キューにデキューされて、置かれます。
All data packets that are transmitted have the latest receive left window edge in the ACK field. Error and control messages may have no ACK [ACK bit off], or set the ACK field to refer to a received packet's sequence number.
伝えられるすべてのデータ・パケットで、最新のものはACK分野で左の窓の優勢を受けます。 誤りとコントロールメッセージは、ACK[食いちぎられたACK]を全く持っていないか、またはACK分野に容認されたパケットの一連番号を参照するように設定するかもしれません。
The RETRANSMIT PROCESS:
再送の過程:
This process can either be viewed as a separate process, or as part of the output packet handler. Its implementation can vary; it could either perform its function, by being woken up at regular intervals, or when the retransmission time occurs for every packet put on the retransmit queue. In the first case the retransmit queue for each TCB is examined to see if there is anything to retransmit. If there is, a packet is placed on the send packet queue of the corresponding TCB. The output packet handler is also signaled.
別々の過程として、または、出力パケット操作者の一部としてこの過程を見なすことができます。 実現は異なることができます。 それは機能を実行するかもしれません、一定の間隔を置いてか、「再-トランスミッション」時間が再送キューに置かれたあらゆるパケットのために起こるという場合に起こされることによって。 各TCBのための前者の場合再送キューは、再送することがあるかどうか確認するために調べられます。 あれば、パケットが置かれる、オンである、対応するTCBのパケット待ち行列を送ってください。 また、出力パケット操作者は合図されます。
Another "demon" process monitors all user Send buffers and retransmittable control messages sent on each connection, but not yet acknowledged. If the global retransmission timeout is exceeded for any of these, the User is notified and he may choose to continue or close the connection. A QUERY packet may also be sent to ascertain the state of the connection [this facilitates recovery from half open connections as described in section 4.3.3].
別の「悪霊」の過程は各接続に送りましたが、まだ承認していなかったすべてのユーザSendバッファとretransmittableコントロールメッセージをモニターします。 グローバルな再送タイムアウトがこれらのどれかのために超えられているなら、Userが通知されて、彼は、接続を続けているか、または終えるのを選ぶかもしれません。 また、接続の状態を確かめるためにQUERYパケットを送るかもしれません[これはセクション4.3.3で説明されるように半分のオープンな接続からの回復を容易にします]。
4.4.6 USER CALL PROCESSING
4.4.6 ユーザ呼び出し処理
OPEN [See figure 3.1]
戸外[3.1が計算するのがわかります]
1. If the process calling does not own the specified local socket,
return with <type 1><ELP 1 "connection illegal for this process">.
1. 過程の呼ぶのが指定された地方のソケットを所有していないなら、1>の<タイプ<ELP1とともに帰ってください、「この過程">"のための接続不法入国者
2. If no foreign socket is specified, construct a new TCB and add
it to the list of existing TCB's. Select a new local connection
name and return it along with <type 1><OLP 0 "success">. If there
is no room for the TCB, respond with <type 1><ELT 4 "No room for
TCB">.
2. どんな外国ソケットも指定されないなら、新しいTCBを組み立ててください、そして、既存のTCBのもののリストにそれを追加してください。 新しい市内接続名を選択してくださいといって、1>の<タイプ<OLP0と共にそれを返してください、「成功">"。 TCBの余地が全くなければ、<で1タイプ><ELT4を反応させてください、「TCB">"の余地がありません。
Cerf, Dalal & Sunshine [Page 36] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[36ページ]RFC675仕様
3. If a foreign socket is specified, verify that there is no
existing TCB with the same <local socket, foreign socket> pair
(i.e. same connection), otherwise return <type l><ELP 6
"connection already open">. If there is no TCB space, return as in
(2), otherwise, create the TCB and link it with the others,
returning a local connection name with the success event code.
3. 外国ソケットが指定されるなら、そうでなければ、同じ<の地方のソケット、外国人のソケット>組(すなわち、同じ接続)、リターン<タイプl><ELP6とどんな既存のTCBもないことを確かめてください、「接続の既に開いている">"。 TCBスペースが全くなければ、(2)のように戻ってください、そして、さもなければ、TCBを作成してください、そして、それを他のものにリンクしてください、成功イベントコードの市内接続名を返して。
Note: if a TCB is created, be sure to copy the timeout parameter
into it, and set the "U" bit to 0 if a foreign socket is
specified, else set U to 1 (to show unspecified foreign socket).
以下に注意してください。 TCBが作成されるなら、タイムアウトパラメタをそれに必ずコピーしてください、そして、外国ソケットが指定されるなら、「U」ビットを0に設定してください、1(不特定の外国ソケットを見せている)へのほかのセットU。
SEND [see figure 3.2]
発信してください。[3.2が計算するのがわかります]
1. Search for TCB with local connection name specified. If none
found, return <type 10><ELP 3 "connection not open">
1. 市内接続名があるTCBの検索は指定しました。 見つけられなかったなにも、リターン<タイプ10><ELP3である、「接続戸外の">"でない
2. If TCB is found, check foreign socket specification. If not set
(i.e. U = 1 in TCB), return <type 10><ELT 5 "foreign socket
unspecified">. If the connection is in the "closing" state (i.e.
state 5 or 6), return <type 3><ELP 12 "connection closing"> and do
not process the buffer.
2. TCBが見つけられるなら、外国ソケット仕様をチェックしてください。 設定されないなら(すなわち、TCBのU=1)、<タイプ10><ELT5を返してください、「外国ソケット不特定の">"。 そして、接続が「終わり」の状態(すなわち、状態5か6)にあるなら、<タイプ3><ELP12を返してください、「接続閉鎖、「>、バッファを処理しないでください、」
3. Put the buffer on the Send buffer queue and signal the
packetizer that there is work to do.
3. Sendバッファ待ち行列にバッファを置いてください、そして、しなければならない仕事があるとpacketizerに合図してください。
INTERRUPT [see figure 3.3]
中断[3.3が計算するのがわかります]
1. Validate existence of the referenced connection, sending out
error messages of the form <type 3><ELP 3 "connection not open">
or <type 3><ELT 5 "foreign socket unspecified"> as appropriate. If
the local connection refers to a connection not accessible to the
process interrupting, send <type 3><ELP 1 "connection illegal for
this process">.
1. 参照をつけられた接続の存在を有効にしてくださいといって、フォーム<に関するエラーメッセージを出して、3><ELP3をタイプしてください、「戸外ではなく、接続、「>か<タイプ3><ELT5、「外国ソケット不特定の「適切な同じくらい>。」 市内接続が過程中断にアクセスしやすくない接続について言及するなら、<タイプ3><ELP1を送ってください、「この過程">"のための接続不法入国者
2. If the connection is in the "closing" state (i.e. states 5 or
6), return <type 3><ELT 12 "connection closing"> and do not send
an INT packet to the destination.
2. そして、接続が「終わり」の状態(すなわち、州5か6)にあるなら、<タイプ3><ELT12を返してください、「接続閉鎖、「>、INTパケットを目的地に送らないでください、」
3. Any pending SEND buffers should be returned with <type 10><ELP
10 "buffer flushed due to interrupt">. An INT packet should be
created and placed on the output packet queue, and the output
packet handler should be signaled.
3. <タイプ10><ELP10と共にどんな未定のSENDバッファも返すべきである、「バッファは中断">"のため洗い流されました。 INTパケットは、出力パケット待ち行列に作成されて、置かれるべきです、そして、出力パケット操作者は合図されるべきです。
RECEIVE [See figure 3.4]
受信してください。[3.4が計算するのがわかります]
1. If the caller does not have access to the referenced local
connection name, return <type 20><ELP 1 "connection illegal for
this process">. And if the connection is not open, return <type
1. 訪問者が参照をつけられた市内接続名に近づく手段を持っていないなら、<タイプ20><ELP1を返してください、「この過程">"のための接続不法入国者 そして、接続がオープンでないなら、<タイプを返してください。
Cerf, Dalal & Sunshine [Page 37] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[37ページ]RFC675仕様
20><ELP 3 "connection not open"). If the connection is in the
closing state (e.g. a FIN has been received or a user CLOSE is
being processed), return <type 20><ELP 12 "connection closing">.
「接続は開かない」20><ELP3) 接続が終わりの状態にあるなら(例えばFINを受け取ったか、またはユーザCLOSEを処理しています)、<タイプ20><ELP12を返してください、「">"を閉じる接続
2. Otherwise, put the buffer on the receive buffer queue and
signal the reassembler that buffer space is available.
2. さもなければ、受信バッファ待ち行列にバッファを置いてください、そして、バッファ領域が利用可能であると「再-アセンブラ」に合図してください。
CLOSE [See figure 3.5]
閉鎖[3.5が計算するのがわかります]
1. If the connection is not accessible to the caller, return <type
2><ELP 1 "connection illegal for this process">. If there is no
such connection respond with <type 2><ELP 3 "connection not
open">.
1. 訪問者には、接続がアクセスしやすくないなら、<タイプ2><ELP1を返してください、「この過程">"のための接続不法入国者 何かそのような接続がなければ<でタイプ2><ELP3を反応させてください、「接続戸外の">"でない。
2. If the R bit is 0 (i.e. connection is in state 1 or 2), simply
remove the TCB.
2. Rビットが0(すなわち、接続が状態1か2にある)であるなら、単にTCBを取り外してください。
3. If the R bit is set and the F bit is set, then remove the TCB.
3. Rビットが設定されて、Fビットが設定されるなら、TCBを取り外してください。
4. Otherwise, if the R bit is set, but F is 0 (i.e. states 3 or
4), return all buffers to the User with <type x><ELP 12
"connection closing">, clear all output and input packet queues
for this connection, create a FIN packet, and signal the output
packet handler. Set the C and F bits to show this action.
4. さもなければ、Rビットが設定されますが、Fが0(すなわち、州3か4)であるなら<タイプx><ELP12とUserにすべてのバッファを返してください、「「>、この接続のためにすべての出力と入力パケット待ち行列をクリアしてください、そして、FINパケットを作成してください、そして、出力パケット操作者に合図してください。」を閉じる接続 CとFビットにこの動作を示すように設定してください。
STATUS [See figure 3.6]
状態[3.6が計算するのがわかります]
1. If the connection is illegal for the caller to access, send
<type 30><ELP 1 "connection illegal for this process">.
1. 訪問者がアクセスするように接続が不法であるなら、<タイプ30><ELP1を送ってください、「この過程">"のための接続不法入国者
2. If the connection does not exist, return <type 30><ELP 3
"connection not open">.
2. 接続が存在しないなら、<タイプ30><ELP3を返してください、「接続戸外の">"でない。
3. Otherwise set status information from the TCB and return it via
<type 30><O-T 0 "status data...">.
3. さもなければ、TCBからの状態情報を設定してください、そして、<タイプ30><O-T0「状態データ」を通してそれを返してください…>。
4.4.7 NETWORK CONTROL PROCESSING
4.4.7 ネットワーク制御処理
The Input Packet Handler examines the header to see if there is any control information or error codes present. We do not discuss the action taken for various special function codes, as it is often implementation dependent, but we describe those that affect the state of the connection. After initial screening by the IPC [see section 4.4.2 and figure 2.2], control and error packets are processed as shown in figures 4.l-4.7. [ACK and data processing is done within the IPC.]
Input Packet Handlerは、何か存在している制御情報やエラーコードがあるかどうか確認するためにヘッダーを調べます。 私たちはそれがしばしば実現に依存していますが、私たちが接続の状態に影響するものについて説明するので様々な特別な機能コードに取られた行動について議論しません。 IPC[セクション4.4.2を見て、2.2について計算する]による一次審査の後に、4.l-4.7が中で計算するのが示されるようにコントロールと誤りパケットは加工処理されます。 [IPCの中でACKとデータ処理をします。]
Cerf, Dalal & Sunshine [Page 38] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[38ページ]RFC675仕様
4.4.8 TCP ERROR HANDLING
4.4.8 TCPエラー処理
Error messages have CD=001 and do not carry user data. Depending on the error, zero or more octets of error information will be carried in the packet text field. We explicitly assume that this data is restricted in length so as to fall below the GATEWAY fragmentation threshold (probably 512 bits of data and header). Errors generally refer to specific connections, so the source and destination socket identifiers are relevant here. The ACK field of an error packet contains the sequence number of the packet that caused the error, and the ACK bit is off. [RESET and STATUS special functions may use the ACK field in the same way.] This allows the receiver of an error message to determine which packet caused the error. Error packets are not ACK'ed or retransmitted.
エラーメッセージは、CD=001を持って、利用者データを運びません。 誤りによって、エラー情報のゼロか、より多くの八重奏がパケットテキストフィールドで運ばれるでしょう。 私たちは、このデータがゲートウェイ断片化敷居(たぶんデータとヘッダーの512ビット)の下に落下するように長さで制限されると明らかに思います。 誤りが一般に特定の接続について言及するので、ソースと目的地ソケット識別子はここで関連しています。 誤りパケットのACK分野は誤りを引き起こしたパケットの一連番号を含んでいます、そして、ACKビットはオフです。 [同様に、RESETとSTATUSの特別な機能はACK分野を使用するかもしれません。] これで、エラーメッセージの受信機は、どのパケットが誤りを引き起こしたかを決定できます。 誤りパケットは、ACK'edでない、また再送されていません。
4.5. BUFFER AND WINDOW ALLOCATION
4.5. バッファAND窓の配分
4.5.1 INTRODUCTION
4.5.1 序論
The TCP manages buffer and window allocation on connections for two main purposes: equitably sharing limited TCP buffer space among all connections (multiplexing function), and limiting attempts to send packets, so that the receiver is not swamped (flow control function). For further details on the operation and advantages of the window mechanism see CEKA74.
TCPは2つの主な目的のための接続のときにバッファと窓の配分を管理します: 公正に、すべての接続(マルチプレクシング機能)と、パケットを送る試みを制限する中で共有はTCPバッファ領域を制限しました、受信機が浸されない(フロー制御機能)ように。 操作に関する詳細とウィンドウメカニズムの利点に関しては、CEKA74を見てください。
Good allocation schemes are one of the hardest problems of TCP design, and much experimentation must be done to develop efficient and effective algorithms. Hence the following suggestions are merely initial thoughts. Different implementations are encouraged with the hope that results can be compared and better schemes developed.
良い配分体系はTCPデザインの最も困難な問題の1つです、そして、効率的で効果的なアルゴリズムを開発するために多くの実験をしなければなりません。したがって、以下の提案は単に初期の考えです。 異なった実現は結果を比較できて、より良い計画が展開したという望みをもって奨励されます。
Several of the measurements discussed in a later section are aimed at providing information on the performance of allocation mechanisms. This should aid in determining significant parameters and evaluating alternate schemes.
後のセクションで議論したいくつかの測定値は配分メカニズムの性能の情報を提供するのを目的とされます。これは重要なパラメタを決定して、交互の計画を評価する際に支援されるべきです。
4.5.2 The SEND Side
4.5.2、側を送ってください。
The window is determined by the receiver. Currently the sender has no control over the SEND window size, and never transmits beyond the right window edge. There exists the possibility of specifying two more special function codes so that the sender can request the receiver to INCREASE or DECREASE the window size, without specifying by how much. The receiver, of course, needn't satisfy this request.
窓は受信機で決定します。現在の送付者は、SENDウィンドウサイズを管理しないで、また正しい窓の縁を超えて決して伝わりません。 送付者がINCREASEに受信機を要求できるように2つのより特別な機能コードを指定する可能性が存在しているか、またはDECREASEはウィンドウサイズを存在させています、いくらで指定しないで。 受信機はもちろんこの要望に応じる必要はありません。
Cerf, Dalal & Sunshine [Page 39] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[39ページ]RFC675仕様
Buffers must be allocated for outgoing packets from a TCP buffer pool. The TCP may not be willing to allocate a full window's worth of buffers, so buffer space for a connection may be less than what the window would permit. No deadlocks are possible even if there is insufficient buffer or window space for one letter, since the receiver will ACK parts of letters as they are put into the user's buffer, thus advancing the window and freeing buffers for the remainder of the letter.
出発しているパケットのためにTCPバッファプールからバッファを割り当てなければなりません。 TCPが完全な窓のバッファの価値を割り当てることを望まないかもしれないので、接続のためのバッファ領域は窓が可能にすること以下であるかもしれません。 どんな行き詰まりも受信機がそうして、不十分なバッファか窓のスペースが1つの文字のためにあってもそれらがあるので手紙のACK部分がユーザのバッファを入れたのが可能ではありません、その結果、窓を進めて、手紙の残りのためのバッファを解放して。
It is not mandatory that the TCP buffer outgoing packets until acknowledgments for them are received, since it is possible to reconstruct them from the actual letters sent by the user.
それらのための承認が受け取られているまでTCPが出発しているパケットをバッファリングするのは、義務的ではありません、ユーザによって送られた実際の手紙からそれらを再建するのが可能であるので。
However, for purposes of retransmission and processing efficiency it is very convenient to do.
しかしながら、「再-トランスミッション」と処理効率の目的はそれが、するために非常に都合がよいです。
4.5.3 The RECEIVE Side
4.5.3、側を受け取ってください。
At the receiving side there are two requirements for buffering:
受信側に、以下をバッファリングするための2つの要件があります。
(l) Rate Discrepancy:
(l) 食い違いを評定してください:
If the sender produces data much faster or much slower than the
receiver consumes it, little buffering is needed to maintain the
receiver at near maximum rate of operation. Simple queuing
analysis indicates that when the production and consumption
(arrival and service) rates are similar in magnitude, more
buffering is needed to reduce the effect of stochastic or bursty
arrivals and to keep the receiver busy.
送付者がはるかに速いか受信機がそれを消費するよりはるかに遅いデータを作り出すなら、バッファリングは、近い最大の稼働率で受信機を維持するのにほとんど必要ではありません。 簡単な列を作り分析は、生産と消費(到着とサービス)率が大きさにおいて同様であるときに、より多くのバッファリングが推計的であるかbursty到着の効果を減少させて、受信機を忙しく保つのに必要であることを示します。
(2) Disorderly Arrivals:
(2) 無秩序な到着:
When packets arrive out of order, they must be buffered until the
missing packets arrive so that packets (or letters) are delivered
in sequence. We do not advocate the philosophy that they be
discarded, unless they have to be, otherwise a poor effective
bandwidth may be observed. Path length, packet size, traffic
level, routing, timeouts, window size, and other factors affect
the amount by which packets come out of order. This is expected to
be a major area of investigation.
パケットが故障していた状態で到着すると、なくなったパケットが到着するまでそれらをバッファリングしなければならないので、連続して、パケット(または、手紙)を届けます。 私たちはそれらが捨てられるという哲学を支持しません。そうする必要はないなら、いてください。さもなければ、貧しい有効な帯域幅は観測されてもよいです。 経路の長さ、パケットサイズ、交通レベル、ルーティング、タイムアウト、ウィンドウサイズ、および他の要素は量にパケットが故障するようになる影響します。 これは主要な研究領域であると予想されます。
The considerations for choosing an appropriate window are as follows:
適切な窓を選ぶための問題は以下の通りです:
Suppose that the receiver knows the sender's retransmission timeout, also, that the receiver's acceptance rate is 'U' bits/sec, and the window size is 'W' bits. Ignoring line errors and other traffic, the sender transmits at a rate between W/K and the maximum line rate (the sender can send a window's worth of data each timeout period).
また、受信機が送付者の再送タイムアウトを知って、受信機の輸入手形決済相場が'U'ビット/秒であり、ウィンドウサイズが'W'ビットであると仮定してください。 線誤りと他の交通を無視して、送付者はW/Kと最大のライン料率の間のレートで伝わります(送付者は各タイムアウト時間に窓のデータの価値を送ることができます)。
Cerf, Dalal & Sunshine [Page 40] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[40ページ]RFC675仕様
If W/K is greater than U, the difference must be retransmissions which is undesirable, so the window should be reduced to W', such that W'/K is approximately equal to U. This may mean that the entire bandwidth of the transmission channel is not being used, but it is the fastest rate at which the receiver is accepting data, and the line capacity is free for other users. This is exactly the same case where the rates of the sender and receiver were almost equal, and so more buffering is needed. Thus we see that line utilization and retransmissions can be traded off against buffering.
それは受信機がデータを受け入れている最も速いレートです、そして、'W/KがUより大きいなら、違いは望ましくない「再-トランスミッション」であるに違いありませんが、したがって、トランスミッションチャンネルの全体の帯域幅は窓がW'に減少するべきです、W'/KがThisが意味するかもしれないU.とほとんど等しいようなものによって使用されていませんが、他のユーザにとって、線路容量は無料です。 これは送付者と受信機のレートがほとんど等しく、とても多くのバッファリングが必要であるまさに同じそうです。 したがって、私たちはその線利用を見ます、そして、バッファリングに対して「再-トランスミッション」を交換できます。
If the receiver does not accept data fast enough (by not performing sufficient RECEIVES) the sender may continue retransmitting since unaccepted data will not be ACK'ed. In this case the receiver should reduce the window size to "throttle" the sender and inhibit useless retransmissions.
受信機が十分速いこと(十分なRECEIVESを実行しないことによって)にデータを受け入れないなら、送付者は、非受諾されたデータがACK'edにならないので再送し続けるかもしれません。 この場合、受信機は、送付者を「阻止し」て、役に立たない「再-トランスミッション」を禁止するためにウィンドウサイズを減少させるはずです。
Receiver window control:
受信機ウィンドウ制御:
If the user at the receiving side is not accepting data, the
window should be reduced to zero. In particular, if all TCP
incoming packet buffers for a connection are filled with received
packets, the window must go to zero to prevent retransmissions
until the user accepts some packets.
受信側のユーザがデータを受け入れていないなら、窓はゼロまで減少するべきです。 接続へのすべてのTCPの入って来るパケットバッファが容認されたパケットで満たされるなら、特に、窓はユーザがいくつかのパケットを受け入れるまで「再-トランスミッション」を防ぎにゼロまで行かなければなりません。
Short term flow control:
短期間フロー制御:
Let F = the number of user receive buffers filled
Fをいっぱいにされたユーザ受信バッファの数との等しさにしてください。
B = the total user receive buffers
Bは総ユーザ受信バッファと等しいです。
W = the long-term or nominal window size
Wは長期的であるか名目上のウィンドウサイズと等しいです。
W' = the window size returned to the sender
'W'は送付者に返されたウィンドウサイズと等しいです。
then a possible value for W' is
'次に、Wのための可能な値'はそうです。
W' = W*[1-F/B]**a
'W'はW*[1F/B]**aと等しいです。
The value of 'a' should be greater than one, in order to shut the
window faster as buffers run out. The values of W' and F actually
used could be averages of recent values, in order to get smooth
control. Note that W' is constantly being recomputed, while the
value of W, which sets the upper limit of W', only changes slowly
in response to other factors.
'a'の値は、バッファがなくなるとき、より速く窓を閉めるもの以上であるべきです。 'Wの値'と実際に使用されるFは、滑らかなコントロールを得る最近の値の平均であるかもしれません。 'W'が絶えず再計算されていることに注意してください、W'の上限を設定するWの値はゆっくり他の要素に対応して変化するだけですが。
The value of W can be large (up to half the sequence number space)
to allow for good throughput on high delay channels. The sender
needn't allocate W worth of buffer space anyway. The long-term
Wの値は、高い遅れチャンネルに関する良い効率を考慮するために大きい場合があります(一連番号スペースの半分)。 送付者はとにかくバッファ領域の価値をWに割り当てる必要はありません。 長期
Cerf, Dalal & Sunshine [Page 41] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[41ページ]RFC675仕様
variation of W to match flow requirements may be a separate
question
流れ要件を合わせるWの変化は別々の問題であるかもしれません。
This short-term mechanism for flow control allows some buffering in the two TCP's at either end, (as much as they are willing), and the rest in the user process at the send side where the data is being created. Hence the cost of buffering to smooth out bursty traffic is borne partly by the TCP's, and partly by the user at the send side. None of it is borne by the communication subnet.
フロー制御のためのこの短期的なメカニズムが中でどちらかの終わりのTCP、(彼らが望んでいるのと同じくらい多く)、およびユーザの残りが処理する2をバッファリングしながらいくつかを許容する、データが作成されている側を送ってください。 したがって、bursty交通が一部TCP、および一部ユーザによって持たれているアウトを整えるバッファリングの費用、側を送ってください。 それのいずれもコミュニケーションサブネットで生まれません。
5. NETWORK MEASUREMENT PLANS FOR TCP
5. ネットワーク測定はTCPの計画を立てます。
5.1 USERLEVEL DIAGNOSTICS
5.1 USERLEVEL病気の特徴
We have in mind a program which will exercise a given TCP, causing it to cycle through a number of states; opening, closing, and transmitting on a variety of connections. This program will collect statistics and will generally try to detect deviation from TCP functional specifications. Clearly there will have to be a copy of this program both at the local site being tested and some site which has a certified TCP. So we will have to produce a specification for this user level diagnostic program also.
私たちは与えられたTCPを運動させるプログラムを考えています、それが多くの州を通って循環することを引き起こして。 さまざまな接続のときに開いて、閉じて、伝わります。 このプログラムは、統計を集めて、一般に、TCPの機能的な仕様からの逸脱を検出しようとするでしょう。 明確に、そこでは、テストされるローカル・サイトと公認されたTCPを持っている何らかのサイトのこのプログラムのコピーになるように、持つでしょう。 それで、私たちはこのユーザレベル診断プログラムのためにも仕様を作り出さなければならないでしょう。
There needs to be a master and a slave side to all this so the master can tell the slave what's going wrong with the test.
そこでは、マスターが、何がテストで支障をきたしているかを奴隷に言うことができるように、マスターと奴隷である必要性がこのすべてに面があります。
5.2 SINGLE CONNECTION MEASUREMENTS
5.2 単独結合測定値
Round trip delay times
周遊旅行遅れ回数
Time from moment the packet is sent by the TCP to the time that
the ACK is received by the TCP.
パケットがTCPによって送られる瞬間からACKがTCPによって受け取られる時間までの時間。
Time from the moment the USER issues the SEND to the time that the
USER gets the successful return code.
USERがSENDを発行する瞬間からUSERがうまくいっている復帰コードを得る時間までの時間。
Note: packet size should be used to distinguish from one set of
round trip times and another.
以下に注意してください。 パケットサイズは、1セットの周遊旅行時間と別のものと区別するのに使用されるべきです。
Network destination, and current configuration and traffic load
may also be issues of importance that must be taken into
account.
目的地をネットワークでつないでください。そうすれば、また、現在の構成とトラヒック負荷は問題であってもよいです考慮に入れなければならない重要性の。
What if the destination TCP decides to queue up ACKs and send a
single ACK after a while? How does this affect round trip
statistics?
目的地TCPがACKsの列を作って、しばらくして独身のACKを送ると決めると、どうなるでしょうか? これはどのように周遊旅行統計に影響しますか?
Cerf, Dalal & Sunshine [Page 42] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[42ページ]RFC675仕様
What about out of order arrivals and the bunched ACK for all of
them?
それらのすべてのための不適切な到着と束ねられたACKはどうですか?
The histogram of round trip times include retransmission times
and these must be taken into account in the analysis and
evaluation of the collected data.
周遊旅行時間のヒストグラムは「再-トランスミッション」回を含んでいます、そして、集まっているデータの分析と評価でこれらを考慮に入れなければなりません。
Packet size statistics
パケットサイズ統計
Histogram of packet length in both directions on the full duplex
connection.
全二重接続に関する両方の方向へのパケット長のヒストグラム。
Histogram of letter size in both directions.
両方の方向への手紙サイズのヒストグラム。
Measure of disorderly arrival
無秩序な到着の手段
Distance from the first octet of arriving packet to the left
window edge. A histogram of this measure gives an idea of the out
of order nature of packet arrivals. It will be 0 for packets
arriving in order.
到着する最初の八重奏から、パケットを左の窓の縁に遠ざけてください。 この測定のヒストグラムはパケット到着の不適切な本質の考えを与えます。 それは整然とした状態で到着するパケットのために0になるでしょう。
Retransmission Histogram
Retransmissionヒストグラム
Effective throughput
有効なスループット
This is the effective rate at which the left edge of the window
advances. The time interval over which the measure is made is a
parameter of the measurement experiment. The shorter the interval,
the more bursty we would expect the measure to be.
これは窓の左の縁が進む実効金利です。 測定が行われる時間間隔は測定実験のパラメタです。 間隔が短ければ短いほど、私たちが、測定は予想するだろうburstyが、より多いです。
It is possible to measure effective data throughput in both
directions from one TCP by observing the rate at which the left
window edge is moving on ACK sent and received for the two
windows.
左の窓の縁が2つの窓に送られて、受け取られたACKを動いている速度を観測することによって1TCPからの両方の指示の有効なデータスループットを測定するのは可能です。
Since throughput is largely dependent upon buffer allocation and
window size, we must record these values also. Varying window for
a fixed file transmission might be a good way to discover the
sensitivity of throughput to window size.
スループットがバッファ配分とウィンドウサイズに主に依存しているので、私たちはこれらの値も記録しなければなりません。 固定ファイルトランスミッションのための異なった窓はスループットの感度をウィンドウサイズに発見する早道であるかもしれません。
Output measurement
出力測定
The throughput measurement is for data only, but includes
retransmission. The output rate should include all octets
transmitted and will give a measure of retransmission overhead.
Output rate also includes packet format overhead octets as well as
data.
スループット測定は、データだけのためにありますが、「再-トランスミッション」を含んでいます。 出力率は、八重奏が伝えたすべてを含むべきであり、「再-トランスミッション」オーバーヘッドの基準を与えるでしょう。 また、出力率はデータと同様にパケット・フォーマットオーバーヘッド八重奏を含んでいます。
Cerf, Dalal & Sunshine [Page 43] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[43ページ]RFC675仕様
Utilization
利用
The effective throughput divided by the output rate gives a
measure of utilization of the communication connection.
有効な出力率が割られたスループットはコミュニケーション接続の利用の手段を与えます。
Window and buffer allocation measurements
窓とバッファ配分測定値
Histogram of letters outstanding, measured at the instant of SEND
receipt by TCP from user or at instant of arrival of a letter for
a receiving user.
ユーザからのTCPによるSEND領収書の瞬間か受信ユーザへの手紙の到着の瞬間に傑出していて、測定された手紙のヒストグラム。
Buffers in use on the SEND side upon packet departure into the
net; buffers in use on the RECEIVE side upon delivery of packet
into a USER Buffer.
SENDで使用中のバッファはパケット出発のときにネットに面があります。 RECEIVEで使用中のバッファはパケットの配送のときにUSER Bufferに面があります。
5.3 MULTICONNECTION MEASUREMENTS
5.3 MULTICONNECTION測定値
Statistics on User Commands sent to the local TCP
地方のTCPに送られたUser Commandsにおける統計
Statistics of error or success codes returned [histogram of each type of error or return response]
誤りか成功コードの統計は戻りました。[それぞれのタイプの誤りかリターン応答のヒストグラム]
Statistics of control bit use
コントロールビット使用の統計
Counter for each control bit over all packets emitted by the TCP
and another for packets accepted
パケットのためにTCPと別のものによって放たれたすべてのパケットの上のそれぞれのコントロールビットカウンタは受け入れました。
Count data carrying packets
パケットを運ぶデータを数えてください。
Count ACK packets with no data
データなしでACKパケットを数えてください。
Error packets distribution by error type code received from the net and sent out into the net
誤りによる誤りパケット分配はネットから受け取られて、ネットに出されたコードをタイプします。
5.4 MEASUREMENT IMPLEMENTATION PHILOSOPHY
5.4 測定実現哲学
We view the measurement process as something which occurs internal to the TCP but which is controllable from outside. A well known socket owned by the TCP can be used to accept control which will select one or more measurement classes to be collected. The data would be periodically sent to a designated foreign socket which would absorb the data for later processing, in the manner currently used in the ARPANET IMPs. Each measurement class has its own data packet format to make the job of parsing and analyzing the data easier.
私たちは起こっていますが、外部からTCPに内部であることで何かであること制御可能なものと測定の過程をみなします。 複数の測定のクラスが集められるのを選択するコントロールを受け入れるのにTCPによって所有されていたよく知られているソケットは使用できます。 定期的に後で処理するためのデータを吸収する指定された外国ソケットにデータを送るでしょう、現在アルパネットIMPsで使用されている方法で。 それぞれの測定のクラスは構文解析の仕事をするそれ自身のデータパケット・フォーマットとデータを解析するのをより簡単にします。
Cerf, Dalal & Sunshine [Page 44] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[44ページ]RFC675仕様
We would restrict access to TCP measurement control to a few designated sites [e.g. NMC, SU-DSL, BBN]. This is easily done by setting up listening control connections on partially specified foreign sockets.
私たちはサイト[例えば、NMC、SU-DSL、BBN]に指定されたいくつかへのTCP測定管理へのアクセスを制限するでしょう。 部分的に指定された外国ソケットの上にコントロール接続を聴きながらセットアップすることによって、容易にこれをします。
6. SCHEDULE OF IMPLEMENTATION
6. 実現のスケジュール
7. REFERENCES
7. 参照
1. CEKA74
1. CEKA74
V. Cerf and R. Kahn, "A Protocol For Packet Network
Intercommunication," IEEE Transactions on Communication, vol. C-
2O, No. 5. May 1974, pp. 637-648.
Communication、vol.C2O、No.5のV.サーフとR.カーン、「パケット網相互通信のためのプロトコル」、IEEE Transactions。 1974年5月、ページ 637-648.
2. CERF74
2. CERF74
V. Cerf, "An Assessment of ARPANET Protocols," in Proceedings of
the Jerusalem Conference on Information Technology, July l974
[RFC#635, INWG Note # ***].
V.サーフ、情報Technology、7月のl974[RFC#635、INWG Note#***]のエルサレムコンファレンスのProceedingsの「アルパネットプロトコルの査定。」
3.CESU74
3. CESU74
V. Cerf and C. Sunshine, "Protocols and Gateways for the
Interconnection of Packet Switching Networks," Proc. of the
Subconference on Computer Nets, Seventh Hawaii International
Conference on Systems Science, January 1974.
サーフ、C.日光、および「パケット交換網のインタコネクトのためのプロトコルとゲートウェイ」に対してProcコンピュータネットのSubconference、システム科学、1974年1月の第7ハワイ国際会議について。
4. HEKA70
4. HEKA70
F. Heart, R.E. Kahn, et al, "The Interface Message Processor for
the ARPA Computer Network," AFIPS 1970 SJCC Proceedings, vol. 36,
Atlantic City, AFIPS Press, New Jersey, pp. 551-567.
F.心臓、R.E.カーン、他、「アルパコンピュータネットワークのためのインタフェース・メッセージ・プロセッサ」、AFIPS1970SJCC Proceedings、vol.36、アトランティックシティー、AFIPS Press、ニュージャージーのページ 551-567.
5. POUZ74
5. POUZ74
L. Pouzin, "CIGALE, the packet switching machine of the CYCLADES
computer network," Proceedings of the IFIP74 Congress, Stockholm,
Sweden.
L.Pouzin、「CIGALE、キクラデス諸島コンピュータネットワークのパケット交換マシン」IFIP74議会のProceedings、ストックホルムスウェーデン。
6. ROWE74
6. ROWE74
L. Roberts and B. Wessler, "Computer Network Development to
achieve resource sharing," AFIPS 1970, SJCC Proceedings, vol. 36,
Atlantic City, AFIPS Press, New Jersey, pp. 543-549.
L.ロバーツとB.Wessler、「リソース・シェアリングを達成するコンピュータNetwork Development」、AFIPS1970、SJCC Proceedings、vol.36、アトランティックシティー、AFIPS Press、ニュージャージーのページ 543-549.
Cerf, Dalal & Sunshine [Page 45] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[45ページ]RFC675仕様
7. POUZ73
7. POUZ73
L. Pouzin, "Presentation and major design aspects of the CYCLADES
Computer Network," Data Networks: Analysis and Design, Third Data
Communications Symposium, St. Petersburg, Florida, November 1973,
pp. 80-87.
L.Pouzin、「プレゼンテーションと少佐はキクラデス諸島コンピュータNetworkの局面を設計する」、Data Networks: 分析とDesign、Third Data Communications Symposium、サンクトペテルブルグフロリダ1973年11月、ページ 80-87.
8. SCWI71
8. SCWI71
R. Scantlebury and P.T. Wilkinson, "The Design of a Switching
System to allow remote Access to Computer Services by other
computers and Terminal Devices," Second Symposium on Problems in
the Optimization of Data Communication Systems Proceedings, Palo
Alto, California, 0ctober 1971, pp. 160-167.
R.ScantleburyとP.T.ウィルキンソン、「他のコンピュータでコンピュータServicesにリモートAccessを許容するSwitching SystemとTerminal DevicesのDesign」、Data Communication Systems Proceedings、パロアルト(カリフォルニア)0ctober1971年のOptimizationのProblems、ページのSecond Symposium 160-167.
9. POST72
9. POST72
J. Postel, "Official Initial Connection Protocol," Current Network
Protocols, Network Information Center, Stanford Research
Institute, Menlo Park, California. January 1972 (NIC 7101).
J.ポステル、「公式の初期の接続プロトコル」、現在のネットワーク・プロトコルはインフォメーション・センター、スタンフォード研究所、メンローパーク、カリフォルニアをネットワークでつなぎます。 1972(NIC7101)年1月。
10. CACR70
10. CACR70
C.S. Carr, S.D. Crocker, and V.G. Cerf, "Host-Host Communication
Protocol in the ARPA Network," AFIPS Conference Proceedings, vol.
36, 1970 SJCC, AFIPS Press, Montvale, N.J.
C.S.カー、サウスダコタ州クロッカー、およびV.G.サーフ、「アーパネットのホスト兼ホスト通信プロトコル」、AFIPSコンファレンスProceedings、vol.36、1970SJCC、AFIPS Press、モントベイルニュージャージー州
11. ZIEL74
11. ZIEL74
H. Zimmerman and M. Elie, "Transport Protocol. Standard Host-Host
Protocol for heterogeneous computer networks," INWG#61, April
1974.
H.ジンマーマンとM.エリー、「プロトコルを輸送してください。」 「異種計算機ネットワークのための標準のHost-ホストプロトコル」、INWG#61、1974年4月。
12. CRHE72
12. CRHE72
S. D. Crocker, J. F. Heafner, R. M. Metcalfe and J. B. Postel,
"Function-oriented protocols for the ARPA Computer Network," AFIPS
Conference Proceedings, vol. 41, 1972 FJCC, AFIPS Press, Montvale,
N.J.
S.D.クロッカーとJ.F.HeafnerとR.M.メトカルフェとJ.B.ポステル、「ARPAコンピュータNetworkのための機能指向のプロトコル」、AFIPSコンファレンスProceedings、vol.41、1972FJCC、AFIPS Press、モントベイルニュージャージー州
13. DALA74
13. DALA74
Y. Dalal, "More on selecting sequence numbers," INWG Protocol Note
#4, October 1974.
Y.Dalal、「さらにセレクティングシーケンス番号」、INWGプロトコルNote#4、1974年10月。
Cerf, Dalal & Sunshine [Page 46] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[46ページ]RFC675仕様
14. SUNS74
14. SUNS74
C. Sunshine, "Issues in communication protocol design -- formal
correctness." INWG Protocol Note #5, October 1974
C.日光、「通信プロトコルでは、デザイン--正式な正当性を発行します」。 INWGプロトコル注意#5、1974年10月
BELS74
BELS74
D. Belsnes, "Note on single message communication," INWG Protocol
Note #3. September 1974.
D.Belsnes、「ただ一つのメッセージ通信に関する注」、INWGプロトコルNote#3。 1974年9月。
16. TOML74
16. TOML74
R. Tomlinson, "Selecting sequence numbers," INWG Protocol Note #2,
September 1974.
R.トムリンスン、「セレクティングシーケンス番号」、INWGプロトコルNote#2、1974年9月。
17. SCHA74
17. SCHA74
R. Schantz, "Reconnection Protocol", private communication;
available from Schantz at BBN.
R.Schantz、「再接続プロトコル」、私信。 Schantzから、BBNで利用可能です。
18. POUZ74A
18. POUZ74A
L. Pouzin, "A proposal for interconnecting packet switching
networks, INWG Note #60, March 1974 [also submitted to EUROCOMP
74].
L.Pouzin、「パケット交換網とインタコネクトする1974[また、EUROCOMP74に提出する]年3月60日のINWG Note#提案。」
19. DLMG74
19. DLMG74
D. Lloyd, M. Galland, and P. T. Kirstein, "Aims and objectives of
internetwork experiments," to be published as an INWG Experiments
Note.
D.ロイド、M.ガランとP.T.カースタイン、「インターネットワークの目的と目的は実験します」INWG Experiments Noteとして発行されるべきである。
20. MCKE73
20. MCKE73
A. McKenzie, "Host-Host Protocol for the ARPANET," NIC # 8246,
Stanford Research Institute [also in ARPANET Protocols Notebook
NIC 7104].
A.マッケンジー、「アルパネットのためのホスト兼ホストプロトコル」、NIC#8246、スタンフォード研究所、[アルパネットプロトコルノートNIC、も7104]。
21. BELS74A
21. BELS74A
D. Belsnes, "Flow control in packet switching networks," INWG Note
#63, October 1974.
D.Belsnes、「パケット交換網によるフロー制御」、INWG Note#63、1974年10月。
Cerf, Dalal & Sunshine [Page 47] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[47ページ]RFC675仕様
FIGURE 1: TCB Major States
1図: TCBの主要な州
0-no TCB
\____________________________________________________________/
OPEN | A CLOSE CLOSE A
---------- | | ---------- ---------- |
set up TCB | | remove TCB remove TCB |
| | |
| | collision retry, |
SYN arrives __V____|__ SEND, INTER |
------------- / S1=0 \ ---------------- |
send SYN, ACK | S2=0 F=0 | send SYN |
______________________| R=0 C=0 |_____________________ |
| | U=0/1 | | |
| | | SYN arrives | |
| error,timeout | 1-OPEN | ----------- | |
| ------------- \__________/ collision; | |
| clear TCB A A set timeout | |
| _____________________| |_____________________ | |
__V____|__ _|___V__|_
/ S1=1 \ / S1=1 \
| S2=0 F=0 | | S2=0 F=0 |
| R=1 C=0 | SYN, ACK arrives | R=0 C=0 |
| U=0/1 | ACK arrives ---------------- | U=0 |
| | ----------- send ACK | |
| 3-SYN rcvd |_________________ _________________| 2-SYN sent |
\__________/ | | \__________/
| __V_____V__
| / S1=1 \
| CLOSE | S2=1 F=0 |
| -------- | R=1 C=0 | FIN arrives
| send FIN | U=0 | -------------------
| | | tell user, send FIN
| ________________|4-established|______________________
| | CLOSE \___________/ |
| | ------- |
__V_____V_ send FIN _______V__
/ S1=1 \ / S1=1 \
| S2=0/1 F=1 | timeout or | S2=1 F=1 |
| R=1 C=1 | FIN, error, arrives CLOSE | R=1 C=0 |
| U=0/1 | ------------------- ---------- | U=0 |
| | remove TCB remove TCB | |
| 5-FIN wait |_____________________ _____________| 6-FIN rcvd |
\__________/ | | \__________/
| |
____________________________V_____V_______________________
/ \
0-no TCB
0いいえ、TCB\____________________________________________________________/戸外| 近い閉鎖A---------- | | ---------- ---------- | TCBをセットアップしてください。| | 取り外し、TCBはTCBを取り外します。| | | | | | 衝突再試行| SYNが到着する、_____|__ 発信、埋葬| ------------- /S1=0\---------------- | SYN、ACKを送ってください。| S2=0F=0| SYNを送ってください。| ______________________| R=0C=0|_____________________ | | | U=0/1| | | | | | SYNは到着します。| | | 誤り、タイムアウト| 開いている1| ----------- | | | ------------- \__________/衝突。 | | | 明確なTCB A Aセットタイムアウト| | | _____________________| |_____________________ | | __V____|__ _|___V__|_ /S1=1\/S1=1\| S2=0F=0| | S2=0F=0| | R=1C=0| SYN、ACKは到着します。| R=0C=0| | U=0/1| ACKは到着します。---------------- | U=0| | | ----------- ACKを送ってください。| | | 3-SYN rcvd|_________________ _________________| 2-SYNは発信しました。| \__________/ | | \__________/ | __V_____V__| /S1=1\| 閉鎖| S2=1F=0| | -------- | R=1C=0| FINは到着します。| FINを送ってください。| U=0| ------------------- | | | ユーザに言ってください、そして、FINを送ってください。| ________________|4で、確立しています。|______________________ | | \を閉じてください。___________/ | | | ------- | __V_____V_はFINを送ります。_______V__/S1=1\/S1=1\| S2=0/1F=1| またはタイムアウト。| S2=1F=1| | R=1C=1| FIN(誤り)が到着する、CLOSE| R=1C=0| | U=0/1| ------------------- ---------- | U=0| | | 取り外し、TCBはTCBを取り外します。| | | 5-FINは待っています。|_____________________ _____________| 6-FIN rcvd| \__________/ | | \__________/ | | ____________________________V_____V_______________________ 0いいえの\について/についてTCB
Cerf, Dalal & Sunshine [Page 48] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[48ページ]RFC675仕様
FIGURE 2.1: Structure of the TCP
2.1は計算します: TCPの構造
| _____________ _______________ |
| | | | | |
| | | | INPUT PACKET |<---->|
| | REASSEMBLER | | HANDLER | |
| |_____________| |_______________| |
| |_______________ | |
| | | |
| _________ | | |
| | | __V_________V____ | NETWORK
|<=====| SYSTEM | | | | or
| | CALLS |<========| TCB's |<========| some
USERS |=====>| or | | and | | NETWORK
| | USER |========>|ASSOCIATED QUEUES|========>| INTERFACE
|<---->|INTERFACE| |_________________| | PROGRAM
| |_________| A A |
| | | |
| ______________| | |
| _______|_____ _______|_______ |
| | | | | |
| | PACKETIZER | | OUTPUT PACKET | |
| | | | HANDLER |<---->|
| |_____________| |_______________| |
| |
| _____________ _______________ | | | | | | | | | | | 入力パケット| <、-、-、--、>|、|、| REASSEMBLER| | 操作者| | | |_____________| |_______________| | | |_______________ | | | | | | | _________ | | | | | | __V_________V____ | ネットワーク|<===| システム| | | | または| | 呼び出し|<====| TCBのもの|<====| いくつかのUSERS|=====>| または| | そして| | ネットワーク| | ユーザ|========>|関連待ち行列|========>| インタフェース| <、-、-、--、>|インタフェース| |_________________| | プログラム| |_________| A| | | | | | ______________| | | | _______|_____ _______|_______ | | | | | | | | | PACKETIZER| | 出力パケット| | | | | | 操作者| <、-、-、--、>|、| |_____________| |_______________| | | |
=======> Logical or physical flow of data (packets/letters)
=======データの>の論理的であるか物理的な流動(パケット/手紙)
-------> "Interaction"
------->「相互作用」
NOTE: The signalling of processes by others is not shown
以下に注意してください。 他のものによる過程を示すことは示されません。
Cerf, Dalal & Sunshine [Page 49] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[49ページ]RFC675仕様
FIGURE 2.2a: ________
Address Check / Begin \
\________/
|
_V_
.' '.
.' packet '.
.' foreign '.
___________________.' socket matches '.
| no '. a TCB local .'
| '. socket .'
| '. ? .'
| '.___.'
| | yes
| _V_
| .' '.
| .' packet '. ___
| .'local socket '. / \
| .' matches fully '.____\| YES |
| '. specified TCB .' / \___/
| '.fgn socket .'
| '. ? .'
_V_ '.___.'
.' '. | no
.' SYN, '. _V_
.'FIN,INT,DSN, '. .' '.
_____.'or text length>0 './_____ .' matches '.
| no '. or QUERY .' \ | .'partly spec. '.
| '. .' |___.' or unspec. TCB '.
| '. ? .' no '. foreign .'
| '.___.' '. socket .'
| | yes '. ? .'
| __________V_________ '.___.'
| | | | yes
| | Create error 7 | _V_
| | packet. Signal OPH | .' '.
| |____________________| .' packet '.
| | ______.' has SYN set '.
| ____V____ | no '. .'
| | | | '. ? .'
|_________\| discard |/________| '.___.'
/|_________|\ |
| _V_
_V_ / \
/ \ | YES |
| NO | \___/
\___/
図2.2a: ________ アドレスは、\\をチェックするか、または始めます。________/ | _'V_'、' ''. パケット'。 '、'、外国、' ___________________''. ソケットは合っています'。 | ''. いいえ、TCBローカル。'| '. ソケット'。| '. ? .' | '.___.' | | はい| _V_| .' '. | ''. パケット'。 ___ | . '地方のソケット'。 / \ | ''. マッチ、完全に'____\| はい| | '. 指定されたTCB'、/、\___/ | '.fgnソケット'。| '. ? ''. _V_'。___.' .' '. | '. 'いいえ、SYN'。 _V_'フィン、INT、DSN' .' '. _____. 'テキスト長さ>0'/_____ ''. マッチ'。 | 'いいえ'QUERY'\| . '一部仕様'。 '. | '. .' |___''. 「非-仕様」。 'Tcb'。 | '. ? '、'、'、外国、'| '.___''.'. ソケット'。| | 'はい'。 ? .' | __________V_________ '.___.' | | | | はい| | 誤り7を作成してください。| _V_| | パケット。 信号OPH| .' '. | |____________________| ''. パケット'。 | | ______''. SYNはセットしましたか?' | ____V____ | 'いいえ'。 .' | | | | '. ? .' |_________\| 破棄|/________| '.___.' /|_________|\ | | _V__V_/\/\| はい| | いいえ| \___/ \___/
Cerf, Dalal & Sunshine [Page 50] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[50ページ]RFC675仕様
FIGURE 2.2b-1: _______
Input Packet Handler / Begin \
\_______/
|
________________________________________\|/_________________________
| A /|\ |
| | | |
| | _V_ |
| | .' '. _______ |
| | .' input '. | go to | |
| | .' packet '.____\| sleep | |
| | '.available.' no /|_______| |
| | '.__?__.' |
| | | yes |
| | _V_ |
| | .' '. |
| .->SPECIAL FUNCT. Fig 4.7 | .'address'. |
| | .->ERR Fig 4.5,4.6 |___.' check OK '. |
| | | .->SYN Fig 4.1,4.2 no '. ? .' |
| | | | .->INT Fig 4.3 '._____.' |
| | | | | .->FIN Fig 4.4 | yes ________|_
| | | | | | _V_ | discard |
| _|_|_|_|_|___________ .' '. |(or queue)|
| | | .' error '. |__________|
|<-| Control Processing |/_________.'or control '. A
|____________________|\ yes '. ? .' |
| '._____.' |
| (INT with data) | no |
| | |
V _V_ |
to "X" .' '. . |
in Fig 2.2b-2 .'(estab)'. .' '. |
_____.' R=S1=S2=1 '.----->.'seq.#'.--->|
| yes '. ? .' no '.OK .' no |
| '._____.' '.' |
| | yes |
| _______________ | |
| | Set S2=1, U=0 | V |
| | Notify user | .'. |
|<--| with event 2 | .'ACK'. |
| | if U was 1 |<-----'. OK .'--->'
| |_______________| yes '. .' no
| '
V
to "Y"
in Fig 2.2b-2
図2.2b-1: _______ 入力パケット操作者/は\\を始めます。_______/ | ________________________________________\|/_________________________ | /|\ | | | | | | | _V_| | | .' '. _______ | | | ''. 入力'。 | 許可| | | | ''. パケット'。____\| 睡眠| | | | '.available'/がありません。|_______| | | | '.__?__.' | | | | はい| | | _V_| | | .' '. | | .->特別である、FUNCT。 図4.7| . 'アドレス'。 | | | .->が間違えている図4.5、4.6|___''. OKをチェックしてください'。 | | | | '.、-、>SYN図4.1、4.2ノー、' ? .' | | | | | '.、-、>INT図4.3、'_____.' | | | | | | .->、フィン、図4.4| はい________|_ | | | | | | _V_| 破棄| | _|_|_|_|_|___________ .' '. |(列を作ってください)| | | | ''. 誤り'。 |__________| | <、-、| コントロール処理|/_________. 'または、制御してください'。 A|____________________|'\はい'。 ? .' | | '._____.' | | (データがあるINT) | いいえ| | | | V_V_| '「X」'、' . | '. '(estab)'という図2.2b-2で。 .' '. | _____''. R=S1=S2=1'。----->'seq#'。--->|、| 'はい'。 ? ''. いいえ、'.OK'、いいえ| | '._____.' '.' | | | はい| | _______________ | | | | S2=1、U=0を設定してください。| V| | | ユーザに通知してください。| .'. | | <--、| 出来事2で| . 'ACK'。 | | | Uが1であったなら| <、-、-、-、--'. 'OK'。---'>'| |_______________| 'はい'。 '、'| '図2.2b-2の「Y」へのV'
Cerf, Dalal & Sunshine [Page 51] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[51ページ]RFC675仕様
FIGURE 2.2b-2: Input Packet Handler (continued)
図2.2b-2: 入力パケット操作者(続けられています)
"Y"
|
.'. _V_
.'txt'. .' '. ______________________________
.'lgth>0 '. .'within '. |Use ACK to advance send window|
,<----'. or DSN .'<---'. window .'--->|Release ACK'ed packets from |
| no '. ? .' no '. ? .' yes |retransmit or send queues. If |
| '._.' '._.' |any packet had EB bit set |
| | yes |remove buffer from Packetized |
| ________V____________________ |buffer queue and inform user |
| |Create ACK packet. Put on | |(success). Signal Packetizer. |
|<-|Send packet queue. Signal OPH| |______________________________|
| |_____________________________| |
| |
| _____________________________________________|
| |
| |
| | "X"
| | |
| _V_ _V_ _____________________
| .' '. .'TCB'. |Put packet on |
| .' text '. yes .'Receive'. yes |Receive packet queue |
| .' length>0 '.-------->.' buffer '.------>|in the right order. |
| '. or DSN .' A '.available.' |Signal Reassembler. |
| '. ? .' | '. ? .' |_____________________|
| '._.' | '._.' |
| | no | | no |
| | | _V_ |
|________\| | .' '. |
/| | .' seq # '. ________ |
| | .' of packet '. yes |Discard | |
| | '. highest so .'---->|packet |----->|
| | '. far .' |________| |
| | '. ? .' |
| | '._.' |
| | | no |
| | _______V______________ |
| | |Discard packet with | |
| |_____|highest seq. no from | |
| |Receive packet queue. | |
| |______________________| |
| |
|_____________________________________________________|
|
V
to "Begin" in Fig 2.2b-1
「Y」| .'. _V_'txt'。 .' '. ______________________________ . 'lgth>0'。 . '中'。 |進歩へのACKが窓を送る使用| <。----'. DSN'、<、'---'. 窓'。--->|ACK'edパケットを放出します。| | 'いいえ'。 ? '、'、' ? '、'、はい。|待ち行列を再送するか、または送ってください。 if| | '._.' '._.' |どんなパケットでも、EBビットを設定しました。| | | はい|Packetizedからバッファを取り除いてください。| | ________V____________________ |待ち行列をバッファリングしてください、そして、ユーザに知らせてください。| | |ACKパケットを作成してください。 置かれます。| |(成功。) Packetizerに合図してください。 | | <、-、|パケット待ち行列を送ってください。 信号OPH| |______________________________| | |_____________________________| | | | | _____________________________________________| | | | | | | 「X」| | | | __V_V______________________ | .' '. . 'Tcb'。 |パケットを置いてください。| | ''. テキスト'. '受信してください'、はい、はい。|パケット待ち行列を受けてください。| | ''. 長さ>0'。--------'>. 'バッファ'。------>|権利では、注文してください。 | | '. DSN. 'A'.available'。|Reassemblerに合図してください。 | | '. ? .' | '. ? .' |_____________________| | '._.' | '._.' | | | いいえ| | いいえ| | | | _V_| |________\| | .' '. | /| | ''. seq#'。 ________ | | | '、'、パケット、'、はい。|破棄| | | | '. 最も高いそう'。---->|パケット|、-、-、-、--、>|、|、| '. 遠くに'|________| | | | '. ? .' | | | '._.' | | | | いいえ| | | _______V______________ | | | |パケットを捨てます。| | | |_____|最も高いseq。| | | |パケット待ち行列を受けてください。 | | | |______________________| | | | |_____________________________________________________| | 図2.2b-1の「始まってください」へのV
Cerf, Dalal & Sunshine [Page 52] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[52ページ]RFC675仕様
FIGURE 2.3-1: Reassembler
図2.3-1: Reassembler
_______
/ Begin \
\_______/
|
|
|<----------------------------------------------.
| _____ | yes
______V_____ .' '. _|_
|Get ready | .' Receive '. yes .'any'.
|for next TCB|--------->.'Packet Queue '.-------->.' more '.
|____________| A '. empty ? .' A '.work?.'
| '._______.' | '._.'
| | no | | no
"R"------>---------' __V__ | ____V____
.' is '. | | Go to |
.' packet '. | | Sleep |
.--<----------------------'.DSN with no.' | |_________|
| yes '. data? .' |
| '.___.' |
| | no |
| __V__ |
| .' '. |
| .' Receive '. yes |
| .'Buffer Queue '.--->|
| '. empty ? .' |
| ________________ '._______.' |
| |Copy from packet| | no |<-------------"S"
| |to buffer until | __V__ |
| |one is exhausted| .'First'. |
| |Update receive | yes .' packet '. no |
| |window. |<----.'matches Recv '.--->'
| |________________| '.left window.'
| | '. edge ?.'
| __V__ '.___.'
| .'Send '.
| .' Packet '. yes _____________________________
| .' Queue empty '.---->|Create ACK packet containing |
| '. ? .' |new window. Signal OPH. |
| '._______.' |_____________________________|
| no | |
| | |
| '--------------------------->|
| |
V V
to "T" to "U"
in Fig 2.3-2 in Fig 2.3-2
_______ /は\\を始めます。_______/ | | |<----------------------------------------------. | _____ | はい______V_____ .' '. _|_ |用意してください。| ''. 受信してください'、はい。. 'いずれも'。 |次のTCBのために|--------->'パケット待ち行列'。--------'>'さらに' |____________| 'A'空ですか? ''. '.work?'。| '._______.' | '._.' | | いいえ| | 「R」がありません。------>、-、-、-、-、-、-、-、--'__V__'| ____V____ '、'、' | | 許可| ''. パケット'。 | | 睡眠| . --<。----------------------'No.がある.DSN| |_________| | 'はい'データ? .' | | '.___.' | | | いいえ| | __V__| | .' '. | | ''. 受信してください'、はい| | . '待ち行列をバッファリングしてください'。--->|、| '. 空であるか、' .' | | ________________ '._______.' | | |パケットからのコピー| | いいえ| <、-、-、-、-、-、-、-、-、-、-、-、--「S」| |バッファリングします。| __V__| | |1つは疲れ果てています。| . '最初に'。 | | |アップデートは受信されます。| 'はい. 'パケット'。| | |窓。 | <、-、-、--. 'Recvを合わせます'。---'>'| |________________| '.leftの窓'。| | '. 縁?'。| __'V__'。___.' | . '発信してください'。 | ''. パケット'、はい。_____________________________ | ''. 空の状態で、列を作ってください'。---->|ACKパケット含有を作成してください。| | '. ? .' |新しい窓。 OPHに合図してください。 | | '._______.' |_____________________________| | いいえ| | | | | | '--------------------------->|、|、| 図2.3-2の図2.3-2の「U」への「T」へのV V
Cerf, Dalal & Sunshine [Page 53] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[53ページ]RFC675仕様
FIGURE 2.3-2: Reassembler (continued)
図2.3-2: Reassembler(続けられています)
"T" "U"
| |
| | _____________
___V____ ___ __V__ |Mark progress|
|process | yes .' '. yes .'whole'. no |in packet. |
| DSN |<-----.' DSN '.<-----.' packet '.--->|Return buffer|--->.
|________| '. set?.' '.copied?.' |to user. | |
| '._.' '.___.' |_____________| |
| | no |
'--------------->| |
| |
__V__ __________________________ |
.' EOL '. yes |Return buffer to user. | |
'. set? .'--------->|Return packet to free |--->|
'.___.' |storage. Signal Packetizer| |
no | |__________________________| |
| A |
__V__ | |
.' full'. | |
'. buffer.'--------------' |
'.___.' yes |
| no |
| |
___________________V__________________ |
|Mark progress in buffer. Return packet| |
|to free storage. Signal Packetizer. | ,--------'
|______________________________________| |
| |
| |
V V
to "R" in Fig 2.3-1 to "S" in Fig 2.3-1
「T」「U」| | | | _____________ ___V____ ___ __V__|マークの進歩| |過程| 'はい'、'、はい. '全体'。|パケットで。 | | DSN| <、-、-、-、--''. DSN'、<。-----''. パケット'。--->|リターンバッファ|--->。 |________| '. セット?'。'.copied?'。|ユーザに。 | | | '._.' '.___.' |_____________| | | | いいえ| '--------------->|、|、|、| __V____________________________ | ''. EOL'、はい。|バッファをユーザに返してください。 | | '. セット?' .'--------->|解放するリターンパケット|、-、--、>| '.___.' |格納。 信号Packetizer| | いいえ| |__________________________| | | A| __V__| | ''. 完全'。 | | '. バッファ'。--------------' | '.___'、'、はい。| | いいえ| | | ___________________V__________________ | |バッファにおける進歩をマークしてください。 リターンパケット| | |格納を解放するために。 Packetizerに合図してください。 | ,--------' |______________________________________| | | | | | 図2.3-1の「S」への図2.3-1の「R」へのV V
Cerf, Dalal & Sunshine [Page 54] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[54ページ]RFC675仕様
FIGURE 2.4: Packetizer
2.4は計算します: Packetizer
_______ ________________________
/ Begin \____________\| Get ready for next TCB |/___________________
\_______/ /|________________________|\ |
| |
__V__ _____ |
.'Send '. .' any '. |
no .' Buffer '. yes .' more '. yes |
.-------------'. Queue .'---->'. work .'-----'
| '.empty? .' A '. ? .'
____________V____________ '.___.' | '.___.'
|Pick packet size depend- | | | no
,-->|ing on send buffer, TCB | | ______V______
| |buffer space, window, etc| | | go to sleep |
| |_________________________| | |_____________|
| | |
| __V__ |
| .'Send '. |
| .' window '. no |
| '.has room ? .'--------------------->|
| '._______.' |
| | yes |
| __V__ |
| .' TCB '. |
| .' buffer '. no |
| .'space avail- '.---------------------'
| '. able ? .' A
| '._______.' |
| | yes |
| _____________V____________ _________|_______ ____________
| |Copy from Send buffer to | |Move buffer from | |Set EOL bit |
| |packet until packet full. | |Send queue to |<--|in packet |
| |Put packet on Send packet | |packetized queue | |header |
| |queue. Signal OPH. | |_________________| |____________|
| |__________________________| A A
| | | no |
| __V__ __|__ |
| .'whole'. .' EOL '. |
| .' Send '. yes .' set in '. yes |
| '. buffer .'----------->'. Send .'-----------'
| '.copied?.' '.buffer?.'
| '.___.' '.___.'
| | no
| _____________V__________
| |Note in TCB where in |
--|Send buffer we stopped. |
|________________________|
_______ ________________________ /は\を始めます。____________\| 次のTCBには、用意してください。|/___________________ \_______/ /|________________________|\ | | | __V_______ | . '発信してください'。 ''. いずれも'。 | '. 'いいえ、Buffer'、はい。. '以上'、はい。| .-------------'. '列を作ってください'。----'>'働いてください、'-----' | '.empty?' ''. A'。 ? .' ____________V____________ '.___.' | '.___.' |選択パケットサイズは依存します。| | | いいえ-->|ing、バッファ、TCBは発信します。| | ______V______ | |バッファ領域、窓など| | | 寝ついてください。| | |_________________________| | |_____________| | | | | __V__| | . '発信してください'。 | | ''. 窓'。| | '.has部屋?' .'--------------------->|、| '._______.' | | | はい| | __V__| | ''. Tcb'。 | | ''. バッファ'。| | . 'スペース利益'。---------------------' | '. できるか、' ''. A| '._______.' | | | はい| | _____________V____________ _________|_______ ____________ | |Sendから、よりもみ皮製で、コピーしてください。| |よりもみ皮製で、動いてください。| |セットEOLビット| | |パケット満までのパケット。 | |待ち行列を送ります。| <--、|パケットで| | |Sendパケットにパケットを置いてください。| |待ち行列をpacketizedしました。| |ヘッダー| | |列を作ってください。 OPHに合図してください。 | |_________________| |____________| | |__________________________| A| | | いいえ| | __V__ __|__ | | . '全体です'。 ''. EOL'。 | | ''. 発信してください'、はい。. '始まってください'、はい。| | '. バッファ'。-----------'>'。 '発信してください'。-----------' | '.copied?'。'.buffer?'。| '.___.' '.___.' | | いいえ| _____________V__________ | |中にTCBにどこを述べてくださいか。| --|私たちが止めたバッファを送ってください。 | |________________________|
Cerf, Dalal & Sunshine [Page 55] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[55ページ]RFC675仕様
FIGURE 2.5a:
Output Packet Handler
_______
/ Begin \
\_______/
|
|<--------------------------.
____________V___________ |
| Get ready for next TCB | |
|________________________| |
| |
,------------------------------------>| |
| __V__ _____ |
| _____ .'Send '. .' any '. |
| yes .' ACK '. no .' Buffer '. yes .' more '. yes |
| .-----'.bit set.'<------'. Queue .'---->'. work .'-----'
| | '.___.' '.empty? .' A '. ? .'
| | no |________ '.___.' | '.___.'
| | |__________ | | no
| ____V__________________ | | |
| |Put latest receive left| ________v______ | ______V______
| |window edge in ACK. |->|Transmit packet| | | go to sleep |
| |_______________________| |_______________| | |_____________|
| | |
| ________________ __V__ |
| |Return packet to| .'pckt '. |_________________
| |buffer pool as | no .'seq # to '. |
| |it has been |<------.'rgt of Send '. |
| |ACKed | '.left window.' |
| |________________| '. edge .' |
| | '.___.' |
| | | yes |
| | _______________V________________ |
| | |Move packet to retransmit queue;| |
| | |set new retrans. time for it. | |
| | |________________________________| |
| | | |
| '---------------------->| |
| __V__ |
| no .'Time '. yes |
-------------------------------.'to switch'.---------------------'
'.TCB's? .'
'.___.'
図2.5a: 出力パケット操作者_______ /は\\を始めます。_______/ | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--. ____________V___________ | | 次のTCBには、用意してください。| | |________________________| | | | ,------------------------------------>|、|、| __V_______ | | _____ . '発信してください'。 ''. いずれも'。 | | 'はい. 'ACK'。いいえ. 'Buffer'、はい。. '以上'、はい。| | .-----'.bitは. '<'を設定しました。------'. '列を作ってください'。----'>'働いてください、'-----' | | '.___''.'.empty?' ''. A'。 ? .' | | いいえ|________ '.___.' | '.___.' | | |__________ | | いいえ| ____V__________________ | | | | |最新の状態で置かれて、左に受信してください。| ________v______ | ______V______ | |ACKの窓の縁。 |、-、>|パケットを伝えてください。| | | 寝ついてください。| | |_______________________| |_______________| | |_____________| | | | | ________________ __V__| | |パケットを返します。| . 'pckt'。 |_________________ | |バッファプール| いいえ、'#、をseqします'。 | | |それはありました。| <、-、-、-、-、--. 'rgt、発信、' | | |ACKed| '.leftの窓'。| | |________________| '. 斜めに進んでください'。| | | '.___.' | | | | はい| | | _______________V________________ | | | |パケットを再送キューに動かしてください;、|| | | |新しいretransそれのための時間を決めてください。 | | | | |________________________________| | | | | | | '---------------------->|、|、| __V__| | いいえ'調節してください'、はい| -------------------------------. '切り替わるように'。---------------------''.TCB?'' .' '.___.'
Cerf, Dalal & Sunshine [Page 56] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[56ページ]RFC675仕様
FIGURE 2.5b: Retransmit Process
図2.5b: 再送の過程
_______
/ Begin \
\_______/
|
|<----------------------------------.
____________V___________ |
| Get ready for next TCB | |
|________________________| |
| |
.-------------------------------->| |
| __V__ |
| .' Any '. _____ |
| .'packet's '. .' any '. |
| .'retrans. time'. no .' more '. yes |
| '. has occurred .'----->'. work .'-----'
| '. for this .' '. ? .'
| '. TCB ? .' '.___.'
| '.___.' |
| | yes | no
| | ______V______
| ________V________ | go to sleep |
| |Move packet to | |_____________|
'------------------------|Send Packet |
|queue. Signal OPH|
|_________________|
_______ /は\\を始めます。_______/ | |<----------------------------------. ____________V___________ | | 次のTCBには、用意してください。| | |________________________| | | | .-------------------------------->|、|、| __V__| | ''. いずれも'。 _____ | | . '、パケット' ''. いずれも'。 | | ''retrans. '. どんな. '以上'も調節しないでください、はい。| | '、起こった、'-----'>'働いてください、'-----' | ''. これのために'、' ? .' | '. Tcb? .' '.___.' | '.___.' | | | はい| いいえ| | ______V______ | ________V________ | 寝ついてください。| | |パケットを動かします。| |_____________| '------------------------|パケットを送ってください。| |列を作ってください。 信号OPH| |_________________|
Cerf, Dalal & Sunshine [Page 57] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[57ページ]RFC675仕様
FIGURE 3.1:
OPEN
_______
/ Begin \
\_______/
|
__V__
.'User '. _______
.'permitted'. no | |
.' access to '.---->|error 1|------------.
'.this local .' |_______| |
'.socket?.' |
'.___.' |
| yes |
__V__ |
.' fgn '. |
yes .' socket '. no |
.-----'. specified .'----. |
| '. ? .' | |
__V__ '.___.' __V__ _______ |
_______ .'conn-'. .'space'. no | | |
| | yes .' ection '. '.for TCB.'---->|error 4|-->|
,-|error 6|<----'. already .' '.___.' |_______| |
| |_______| '.exists?.' | yes |
| '.___.' | |
| | no ____V__________ |
| _______ __V__ |Create TCB. Set| |
| | | no .'space'. |S1=S2=R=F=C=1 | |
|<-|error 4|<-----'.for TCB.' |Set U=1 | |
| |_______| '.___.' |_______________| |
| | yes | |
| | | |
| _________V__________ | |
| |Create TCB. Set U=0 | | |
| |Set S1=S2=R=F=C=1 | | |
| |____________________| | |
| | | |
| '-------------.-------------' |
| | |
| _____________________V__________________ |
| |Return local connection name and Success| |
| |________________________________________| |
| | |
----------------------------------->|<--------------------------------'
____V___
/ Return \
\________/
3.1は計算します: 戸外_______ /は\\を始めます。_______/ | __V__'ユーザ'。 _______ . '受入れられて'、いいえ| | ''. アクセス、'---->|誤り1|------------. '.this地方です'。|_______| | '.socket?'。| '.___.' | | はい| __V__| ''. fgn'。 | 'はい. 'ソケット'。| .-----'、指定、'----. | | '. ? .' | | __'V__'。___''_. _V_________ | _______ . 'コン'。 . 'スペース'。| | | | | 'はい. 'ection'。 '.for TCB'。---->|誤り4| -->、| ,-|誤り6| <、-、-、--''. 既に、'、'___.' |_______| | | |_______| '.exists?'。| はい| | '.___.' | | | | いいえ____V__________ | | _______ __V__|TCBを作成してください。 セットします。| | | | | いいえ'スペース'。 |S1=S2=R=FはC=1と等しいです。| | | <、-、|誤り4| <、-、-、-、--'.for TCB'。|U=1を設定してください。| | | |_______| '.___.' |_______________| | | | はい| | | | | | | _________V__________ | | | |TCBを作成してください。 U=0を設定してください。| | | | |C S1=S2=R=F==1を設定してください。| | | | |____________________| | | | | | | | '-------------.-------------' | | | | | _____________________V__________________ | | |市内接続の名前とSuccessを返してください。| | | |________________________________________| | | | | ----------------------------------->|<--------------------------------' ____V___ /リターン\\________/
Cerf, Dalal & Sunshine [Page 58] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[58ページ]RFC675仕様
FIGURE 3.2:
SEND
_______
/ Begin \
\_______/
|
__V__
.'conn-'.
.' ection '. _________
.' legal for '. no | |
'. this process .'---------->| error 1 |-----------.
'. ? .' |_________| |
'._______.' |
| yes |
__V__ |
.'conn-'. _________ |
.' ection '. no | | |
.' open '.----------->| error 3 |---------->|
'. ? .' |_________| |
'._______.' |
| yes |
__V__ |
.' fgn '. _________ |
.' socket '. no | | |
'. specified .'------------>| error 5 |---------->|
'.(U=0)? .' |_________| |
'.___.' |
| yes |
__V__ |
.'conn-'. _________ |
.' ection '. yes | | |
'. closing ? .'------------>| error 12|---------->|
'.(F,C=1).' |_________| |
'.___.' |
| no |
____________________V________________________________ |
|Put buffer on Send Buffer queue and signal Packetizer| |
|_____________________________________________________| |
| |
|<-----------------------------------------'
____V___
/ Return \
\________/
3.2は計算します: 発信してください。_______ /は\\を始めます。_______/ | __V__'コン'。 ''. ection'。 _________ '、'、法的である、'| | '. この過程'。---------->| 誤り1|-----------. '. ? .' |_________| | '._______.' | | はい| __V__| . 'コン'。 _________ | ''. ection'。| | | ''. 開いてください'。----------->| 誤り3|、-、-、-、-、-、-、-、-、--、>| '. ? .' |_________| | '._______.' | | はい| __V__| ''. fgn'。 _________ | ''. ソケット'。| | | '、指定、'------------>| 誤り5|、-、-、-、-、-、-、-、-、--、>| '. (U=0?)' .' |_________| | '.___.' | | はい| __V__| . 'コン'。 _________ | ''. ection'、はい。| | | '. 閉鎖?' .'------------>| 誤り12|、-、-、-、-、-、-、-、-、--、>| '. (F、C=1)'。|_________| | '.___.' | | いいえ| ____________________V________________________________ | |Send Buffer待ち行列と信号Packetizerにバッファを置いてください。| | |_____________________________________________________| | | | |<-----------------------------------------' ____V___ /リターン\\________/
Cerf, Dalal & Sunshine [Page 59] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[59ページ]RFC675仕様
FIGURE 3.3: INTERRUPT
3.3は計算します: 中断
_______
/ Begin \
\_______/
|
|
V
_______ /は\\を始めます。_______/ | | V
Same as SEND
発信するのと同じです。
| |
| |
____________________V_________________________ |
|Return any pending Send buffers with code 10. | |
|Create INT packet on outgoing packet queue. | |
|Signal Output Packet Handler. | |
|______________________________________________| |
| |
|<-----------------------------------------'
____V___
/ Return \
\________/
| | | | ____________________V_________________________ | |コード10があるあらゆる未定のSendバッファを返してください。 | | |外向的なパケット待ち行列のときにINTパケットを作成してください。 | | |出力パケット操作者に合図してください。 | | |______________________________________________| | | | |<-----------------------------------------' ____V___ /リターン\\________/
Cerf, Dalal & Sunshine [Page 60] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[60ページ]RFC675仕様
FIGURE 3.4:
RECEIVE
_______
/ Begin \
\_______/
|
__V__
.'conn-'.
.' ection '. _________
.' legal for '. no | |
'. this process .'---------->| error 1 |-----------.
'. ? .' |_________| |
'._______.' |
| yes |
_V_ |
.' '. |
.' '. |
.'connection '. |
.' state '. |
:___________________: _________ |
| | | | | |
1-4 | 5,6 | 0 '-------------------->| error 3 |-->|
| '---------------------. |_________| |
__________V__________ | |
|Put buffer on Receive| | _________ |
|Buffer queue. Signal | | | | |
|Reassembler | '----->| error 12|-->|
|_____________________| |_________| |
| |
|<------------------------------------------------'
____V___
/ Return \
\________/
3.4は計算します: 受信してください。_______ /は\\を始めます。_______/ | __V__'コン'。 ''. ection'。 _________ '、'、法的である、'| | '. この過程'。---------->| 誤り1|-----------. '. ? .' |_________| | '._______.' | | はい| _V_| .' '. | .' '. | . '接続'。 | ''. 状態'。 | :___________________: _________ | | | | | | | 1-4 | 5,6 | 0 '-------------------->| 誤り3| -->、|、| '---------------------. |_________| | __________V__________ | | |バッファをReceiveに置いてください。| | _________ | |待ち行列をバッファリングしてください。 信号| | | | | |Reassembler| '----->| 誤り12| -->、| |_____________________| |_________| | | | |<------------------------------------------------' ____V___ /リターン\\________/
Cerf, Dalal & Sunshine [Page 61] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[61ページ]RFC675仕様
FIGURE 3.5:
CLOSE
_______
/ Begin \
\_______/
|
__V__
.'conn-'.
.' ection '. _________
.' legal for '. no | |
'. this process .'---------->| error 1 |-----------.
'. ? .' |_________| |
'._______.' |
| yes |
_V_ |
.' '. |
.' '. |
.'connection '. |
.' state '. |
:___________________: _________ |
5| |3,4 |1,2,6 |0 | | |
| | | '------------------>| error 3 |-->|
,------------' | '-------------------. |_________| |
| ______________V______________________ | |
| |Return all buffers to user with error| | ___________ |
| |12; clear all packet queues, create | | |Remove TCB | |
| |FIN packet, signal Output Packet | '--->|Return |--->|
| |Handler, set C=F=1 | |Success | |
| |_____________________________________| |___________| |
| | |
--------------------->|<----------------------------------------'
____V___
/ Return \
\________/
3.5は計算します: 閉鎖_______ /は\\を始めます。_______/ | __V__'コン'。 ''. ection'。 _________ '、'、法的である、'| | '. この過程'。---------->| 誤り1|-----------. '. ? .' |_________| | '._______.' | | はい| _V_| .' '. | .' '. | . '接続'。 | ''. 状態'。 | :___________________: _________ | 5| |3,4 |1,2,6 |0 | | | | | | '------------------>| 誤り3| -->、| ,------------' | '-------------------. |_________| | | ______________V______________________ | | | |誤りと共にすべてのバッファをユーザに返してください。| | ___________ | | |12; すべてのパケット待ち行列をクリアしてください、作成| | |TCBを取り外してください。| | | |FINパケット、信号Output Packet| '--->|リターン|、-、--、>|、| |操作者、FセットC==1| |成功| | | |_____________________________________| |___________| | | | | --------------------->|<----------------------------------------' ____V___ /リターン\\________/
Cerf, Dalal & Sunshine [Page 62] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[62ページ]RFC675仕様
FIGURE 3.6:
STATUS
_______
/ Begin \
\_______/
|
__V__
.'conn-'.
.' ection '. _________
.' legal for '. no | |
'. this process .'---------->| error 1 |-----------.
'. ? .' |_________| |
'._______.' |
| yes |
__V__ __________ |
.'conn-'. |Return | |
.' ection '. no |state=0 or| |
'. open ? .'------------>|error 3 |--------->|
'._______.' |__________| |
| yes |
___________V___________ |
|Fill in reply from TCB.| |
|Return Success to user.| |
|_______________________| |
| |
|<-----------------------------------------'
____V___
/ Return \
\________/
3.6は計算します: 状態_______ /は\\を始めます。_______/ | __V__'コン'。 ''. ection'。 _________ '、'、法的である、'| | '. この過程'。---------->| 誤り1|-----------. '. ? .' |_________| | '._______.' | | はい| __V____________ | . 'コン'。 |リターン| | ''. ection'。|または=0を述べてください。| | '. 戸外?' .'------------>|誤り3|、-、-、-、-、-、-、-、--、>| '._______.' |__________| | | はい| ___________V___________ | |TCBから回答に記入してください、|| |Successをユーザに返してください、|| |_______________________| | | | |<-----------------------------------------' ____V___ /リターン\\________/
Cerf, Dalal & Sunshine [Page 63] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[63ページ]RFC675仕様
FIGURE 4.1:
SYN (no ACK)
_______
/ Begin \
\_______/
|
_V_
.' '.
.' '.
.' S1, S2, R '.
.' ? '.
:___________________: 1,1,1 _________
__________ | | | | (states 4-6) | |
|Treat as a| 1,0,1 | | | '------------->| error 6 |-->.
|duplicate.|<-----------' | | |_________| |
|Retransmit| | | 1.0,0 |
|SYN, ACK | 0,0,0 | | (Syn sent) ________________ |
|__________| (listening) | '------------>|Collision: Clear| |
| | |S1, set timeout,| |
| _____________________V________________ |remove SYN from |-->|
| |Set R=S1=1. If U=1 set foreign socket | |retransmit queue| |
| |in TCB to match packet local socket. | |________________| |
| |Send SYN, ACK. Signal OPH. Fill in TCB| |
| |with send window, receive sequence #. | |
| |______________________________________| |
| | |
| | |
'----------------------->|<---------------------------------------'
___V__
/ Done \
\______/
4.1は計算します: SYN(ACKがありません)_______ /は\\を始めます。_______/ | _'V_'、' .' '. ''. S1、S2、R'。 .' ? '. :___________________: 1,1,1 _________ __________ | | | | (州4-6) | | |aとして、扱ってください。| 1,0,1 | | | '------------->| 誤り6|-->。 |写し| <。-----------' | | |_________| | |再送してください。| | | 1.0,0 | |SYN、ACK| 0,0,0 | | (送られたSyn) ________________ | |__________| (聴取) | '------------>|衝突: クリアしてください。| | | | |S1、タイムアウトを設定してください。| | | _____________________V________________ |SYNを取り外します。| -->、|、| |R=S1=1を設定してください。 U=1が外国ソケットを設定するなら| |再送キュー| | | |パケットの地方のソケットを合わせるTCBで。 | |________________| | | |SYN、ACKを送ってください。 OPHに合図してください。 TCBに記入してください。| | | |窓を送ってください、そして、系列#を受け取ってください。| | | |______________________________________| | | | | | | | '----------------------->|<---------------------------------------' ___V__/された\\______/
Cerf, Dalal & Sunshine [Page 64] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[64ページ]RFC675仕様
FIGURE 4.2: SYN,ACK
4.2は計算します: SYN、ACK
_______
/ Begin \
\_______/
|
__V__
.' '.
.' State 2 '. no
'.S1=1;S2=R=0.'----------------.
'. ? .' |
'.___.' |
| yes |
__V__ _______V______
.' ACK '. no | |
.' correct '.-------->| send error 6 |
'. ? .' |______________|
'.___.' |
| yes |
_________V_________ |
|Set S2=R=1. Process| |
|ACK. Send ACK. | |
|___________________| |
| |
|<----------------------'
___V__
/ Done \
\______/
_______ /は\\を始めます。_______/ | __'V__'、' ''. 2を述べてください'。いいえ、'.S1=1; S2=R=0'----------------. '. ? .' | '.___.' | | はい| __V_________V______ ''. ACK'。| | '、'、正しさ、'-------->| 送信エラー6| '. ? .' |______________| '.___.' | | はい| _________V_________ | |S2=R=1を設定してください。 過程| | |ACK。 ACKを送ってください。 | | |___________________| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--' ___V__/された\\______/
Cerf, Dalal & Sunshine [Page 65] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[65ページ]RFC675仕様
FIGURE 4.3:
INT (from net)
_______ ____________
/ Begin \____\|Process ACK |
\_______/ /|(may set S2)|------.
|____________| |
|
__V__
____________ .' in '.
| Discard | no .' state 4 '.
.<-------| (or queue) |<-------'. S1=S2=R=1 .'
| |____________| '. F=0 ? .'
| '.___.'
| | yes
| __V__
| ____________ .' '.
| | ACK and | no .' within '.
|<-------| discard |<-------'. window .'
| |____________| '. ? .'
| '.___.'
| | yes
| ____________________________V_______________
| |Move Receive Left window edge to sequence |
| |number of INT. Return event 10 with any |
| |pending Receive buffers. Ruturn event 11 to |
| |user. Send ACK for INT. |
| |____________________________________________|
| |
| __V__
| see yes .'data '.
| Figure<----------.' in this '.
| 2.2 '.packet?.'
| '.___.'
| | no
'------------------------------------>|
___V__
/ Done \
\______/
4.3は計算します: INT(ネットからの)_______ ____________ /は\を始めます。____\|過程ACK| \_______/ /|(S2を設定するかもしれません)|------. |____________| | | __V______________ ''. コネ'。 | 破棄| 'いいえ'4を'述べてください。 . <。-------| (列を作ってください) | <、-、-、-、-、-、--'. 'S1=S2=R=1'。| |____________| '. 'F=0?'。| '.___.' | | はい| __V__| ____________ .' '. | | そしてACK。| 'いいえ'中' | <、-、-、-、-、-、--、| 破棄| <、-、-、-、-、-、--'. 窓'。| |____________| '. ? .' | '.___.' | | はい| ____________________________V_______________ | |Receive Left窓の縁を系列に動かしてください。| | |INTの数。 いずれがあるリターン出来事10| | |未定のReceiveバッファ。 出来事11をRuturnします。| | |ユーザ。 INTのためにACKを送ってください。 | | |____________________________________________| | | | __V__| はい'データ'を見てください。 | 図<。----------''. コネ、これ、' | 2.2 '.packet?'。| '.___.' | | 'いいえ'------------------------------------>| ___V__/された\\______/
Cerf, Dalal & Sunshine [Page 66] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[66ページ]RFC675仕様
FIGURE 4.4:
FIN
_______ ____________
/ Begin \____\|Process ACK |
\_______/ /|(may set S2)|------.
|____________| |
|
__V__
.' '.
no .'S1=S2=R=1'.
.--------------'. (estab- .'
| '.lished).'
| '.___.'
| | yes
| __V__
______V_____ .' '.
| | no .' within '.
.-----------------| discard |<-------'. window .'
| |____________| '. ? .'
| '.___.'
| | yes
| __V__
| (state 4) 0 .'F bit'. 1 (state 5)
| .------------'. value .'------------.
| | '.___.' |
| _________________________V________ |
| |Return all user buffers (event 12)| _____________________V__
| |Clear all packet queues. Send FIN | |Return success to User's|
| |packet. Set F=1. Inform user | |CLOSE. Remove TCB. |
| |"connection closing" (event 12) | |________________________|
| |__________________________________| |
| | |
'----------------->|<-----------------------------------'
___V__
/ Done \
\______/
4.4は計算します: フィン_______ ____________ /は\を始めます。____\|過程ACK| \_______/ /|(S2を設定するかもしれません)|------. |____________| | | __'V__''. . 'S1=S2=R=1'でない。 .--------------'. '(estab. '| '.lished)'.' | '.___.' | | はい| __V________V_____ .' '. | | 'いいえ'中' .-----------------| 破棄| <、-、-、-、-、-、--'. 窓'。| |____________| '. ? .' | '.___.' | | はい| __V__| (状態4) 0 . 'Fに噛み付きました'。 1 (状態5)| .------------'. 値'。------------. | | '.___.' | | _________________________V________ | | |すべてのユーザバッファ(出来事12)を返してください。| _____________________V__| |すべてのパケット待ち行列をクリアしてください。 フィンを送ってください。| |Userのものに成功を返してください。| | |パケット。 F=1を設定してください。 ユーザに知らせてください。| |閉じてください。 TCBを取り外してください。 | | |「接続閉鎖」(出来事12)| |________________________| | |__________________________________| | | | | '----------------->|<-----------------------------------' ___V__/された\\______/
Cerf, Dalal & Sunshine [Page 67] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[67ページ]RFC675仕様
FIGURE 4.5: Error 6 (bad SYN)
4.5は計算します: 誤り6(悪いSYN)
_______
/ Begin \
\_______/
|
|
__V__
.' '.
.'refers to'.
.'current pckt?'. _________
.'(ACK matches seq '. no | |
'. # of packet on .'----------------->| discard |-----------.
'.retrans or send.' |_________| |
'. queues?) .' |
'._______.' |
| yes |
| |
_V_ |
.' '. 1 (state 3) |
.' value '.--------------------------------. |
'. of R.' bad SYN,ACK | |
'._.' | |
| | |
| 0 (state 2) | |
| bad SYN | |
__________________V__________________ _______V______ |
|Other side is established. Send RESET| |Clear S1, R | |
|(put error packet's seq. # in ACK | |Remove SYN,ACK| |
|field. Return all user buffers with | |from retrans | |
|code 14. Inform user with event 14 | |queue. | |
|_____________________________________| |______________| |
| | |
| V |
|<--------------------------------------------------'
___V__
/ Done \
\______/
_______ /は\\を始めます。_______/ | | __'V__'、' . '言及します'。 . '現在のpckt?'。 _________ .'(ACK matches seq '. no | | '. # of packet on .'----------------->| discard |-----------. '.retrans or send.' |_________| | '. queues?) .' | '._______.' | | はい| | | _V_| .' '. 1 (状態3)| ''. 値'。--------------------------------. | '. '悪いR.SYNについてACK| | '._.' | | | | | | 0 (状態2)| | | 悪いSYN| | __________________V__________________ _______V______ | |反対側は確立されます。 リセットを送ってください。| |明確なS1、R| | |(put error packet's seq. # in ACK | |Remove SYN,ACK| | |field. Return all user buffers with | |from retrans | | |code 14. Inform user with event 14 | |queue. | | |_____________________________________| |______________| | | | | | V | |<--------------------------------------------------' ___V__ / Done \ \______/
Cerf, Dalal & Sunshine [Page 68] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[68ページ]RFC675仕様
FIGURE 4.6: Error 7,8
4.6は計算します: 誤り7、8
_______
/ Begin \
\_______/
|
__V__
.' '.
.'refers to'. _________
.' current '. no | |
'. packet (check .'---------------->| discard |-----------.
'. ACK)? .' A |_________| |
'._______.' | |
| yes | |
_V_ | |
.' '. | |
.' '. | |
.'connection '. | |
.' state '. | |
:___________________: | |
4| 5| 3| 2| 6| | |
.-------' | | | '------' |
| | | '-----------------------------. |
| | '-------------. | |
| | | | |
___V___ ____V_______ ______V_______ ________V_________ |
|Pass to| |Remove TCB. | |Clear S1, R. | |Discard. SYN will | |
|user | |Return | |Remove SYN,ACK| |be retrans to | |
|_______| |success to | |from transmit | |avoid receiver | |
| |user's CLOSE| |queue (go to | |having to queue it| |
| |____________| |state 1). | |__________________| |
| | |______________| | |
| V | V |
'------------------------------>|<---------------------------------'
___V__
/ Done \
\______/
_______ /は\\を始めます。_______/ | __'V__'、' . '言及します'。 _________ ''. 電流'。| | '. packet (check .'---------------->| discard |-----------. '. ACK)? ''. A|_________| | '._______.' | | | はい| | _V_| | .' '. | | .' '. | | . '接続'。 | | ''. 状態'。 | | :___________________: | | 4| 5| 3| 2| 6| | | .-------' | | | '------' | | | | '-----------------------------. | | | '-------------. | | | | | | | ___V___ ____V_______ ______V_______ ________V_________ | |通ります。| |TCBを取り外してください。 | |S1、Rをクリアしてください。| |捨ててください。 SYNはそうするでしょう。| | |ユーザ| |リターン| |SYN、ACKを取り外してください。| |retransします。| | |_______| |成功| |伝える| |受信機を避けてください。| | | |ユーザのCLOSE| |queue (go to | |having to queue it| | | |____________| |state 1). | |__________________| | | | |______________| | | | V| V| '------------------------------>|<---------------------------------' ___V__/された\\______/
Cerf, Dalal & Sunshine [Page 69] RFC 675 Specification of Internet TCP December 1974
サーフ、インターネットTCP1974年12月のDalalと日光[69ページ]RFC675仕様
FIGURE 4.7:
RESET
_______
/ Begin \
\_______/
|
__V__
no .'Reset'. yes
.------------'. All ? .'------------------.
| '.___.' |
| _________V_________
| |Clear all TCB's for|
| |foreign TCP. Inform|
| |users with event 14|
| |___________________|
__V__ |
.' Is '. _________ |
.' RESET '. no | | |
.'believable ? '.------->| discard |------------->|
'.(check ACK .' |_________| |
'.field) .' |
'.___.' |
| yes |
________________V________________ |
|Clear all queues for this TCB. | |
|Return event 14 for user buffers.| |
|Inform User with event 14. | |
|_________________________________| |
| |
|<----------------------------------------'
___V__
/ Done \
\______/
4.7は計算します: リセット_______ /は\\を始めます。_______/ | __V__いいえ'リセット'はい。------------'. すべて? .'------------------. | '.___.' | | _________V_________ | |TCBのすべてのものをきれいにします。| | |外国TCP。 知らせてください。| | |出来事14を伴うユーザ| | |___________________| __V__| '、'、' _________ | ''. RESET'。| | | '信用できる?' '.------->| 破棄|、-、-、-、-、-、-、-、-、-、-、-、--、>| '.(check ACK .' |_________| | '.field) .' | '.___.' | | はい| ________________V________________ | |このTCBのためにすべての待ち行列をクリアしてください。 | | |ユーザバッファのために出来事14を返してください、|| |出来事14でUserに知らせてください。 | | |_________________________________| | | | |<----------------------------------------' ___V__/された\\______/
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 2/2000 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社2/2000]
Cerf, Dalal & Sunshine [Page 70]
サーフ、Dalal、および日光[70ページ]
一覧
スポンサーリンク
