RFC887 日本語訳
0887 Resource Location Protocol. M. Accetta. December 1983. (Format: TXT=36770 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Accetta
Request for Comments: 887 Carnegie-Mellon University
December 1983
Accettaがコメントのために要求するワーキンググループM.をネットワークでつないでください: 887 カーネギーメロン大学1983年12月
RESOURCE LOCATION PROTOCOL
リソース位置のプロトコル
This note describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet. This RFC specifies a draft standard for the ARPA Internet community.
この注意はARPAインターネットでの使用のためにリソース位置のプロトコルについて説明します。 ブロードキャスト・アドレッシングの何らかのメソッドをサポートする技術を使うネットワークで最も役に立つ、しかしながら、また、それは他のタイプのネットワークで使用されるかもしれません。 最大限の利益、どれが重要なリソースを提供するか、そして、インターネットの他のホストに対するサービスがこのプロトコルであると実装するべきであるすべてのホストのために。 Resource Locationがプロトコルであると実装しないホストは、他のホストによって無視される危険を冒します(インターネットにリソースの場所を見つけるのを試みています)。 このRFCはARPAインターネットコミュニティの草稿規格を指定します。
The Resource Location Protocol (RLP) utilizes the User Datagram Protocol (UDP) [1] which in turn calls on the Internet Protocol (IP) [3] to deliver its datagrams. See Appendix A and [6] for the appropriate port and protocol number assignments.
Resource Locationプロトコル(RLP)はインターネットプロトコル(IP)[3]がデータグラムを提供するよう順番に呼びかけるユーザー・データグラム・プロトコル(UDP)[1]を利用します。適切なポートとプロトコル番号課題に関してAppendix Aと[6]を見てください。
Unless otherwise indicated, all numeric quantities in this document are decimal numbers.
別の方法で示されない場合、すべての数値量が本書では10進数です。
1. Introduction
1. 序論
From time to time, Internet hosts are faced with the problem of determining where on the Internet some particular network service or resource is being provided. For example, this situation will arise when a host needs to send a packet destined for some external network to a gateway on its directly connected network and does not know of any gateways. In another case, a host may need to translate a domain name to an Internet address and not know of any name servers which it can ask to perform the translation. In these situations a host may use the Resource Location Protocol to determine this information.
時々、インターネット・ホストはインターネットでは、何らかの特定のネットワーク・サービスかリソースがどこに提供されているかを決定するという問題に直面しています。 ホストが何らかの外部のネットワークのために直接接続されたネットワークでゲートウェイに運命づけられたパケットを送るのが必要であり、どんなゲートウェイも知らないとき、例えば、この状況は起こるでしょう。 別の場合では、ホストは、ドメイン名をインターネット・アドレスに翻訳して、それが翻訳を実行するように頼むことができるどんなネームサーバも知らない必要があるかもしれません。 これらの状況で、ホストは、この情報を決定するのにResource Locationプロトコルを使用するかもしれません。
In almost all cases the resource location problem is simply a matter of finding the IP address of some one (usually any) host, either on the directly connected network or elsewhere on the Internet, which understands a given protocol. Most frequently, the querying host itself understands the protocol in question. Typically (as in the case of locating a name server), the querying host subsequently intends to employ that protocol to communicate with the located host once its address is known (e.g. to request name to address translations). Less frequently, the querying host itself does not necessarily understand the protocol in question. Instead (as in the case of locating a gateway), it is simply attempting to find some other host which does (e.g. to determine an appropriate place to forward a packet which cannot be delivered locally).
ほとんどすべての場合リソース位置問題は単に与えられたプロトコルを理解しているインターネットの直接接続されたネットワークかほかの場所のどちらかのおよそ1人(通常いくらか)のホストのIPアドレスを見つける問題です。 最も頻繁に、質問しているホスト自身は問題のプロトコルを理解しています。 通常(ネームサーバの場所を見つけるケースのように)、質問しているホストは、次に、アドレスがいったん知られていた(例えば、アドレス変換への要求名に)あとに見つけられたホストとコミュニケートするのにそのプロトコルを使うつもりです。 どんなより頻繁にも、質問しているホスト自身は必ず問題のプロトコルを理解していないというわけではありません。 代わりに(ゲートウェイの場所を見つけるケースのように)、それは、そうするある他のホスト(例えば局所的に提供できないパケットを進める適切な場所を決定する)を見つけるのを単に試みています。
Accetta [Page 1] RFC 887 December 1983 Resource Location Protocol
Accetta[1ページ]RFC887 1983年12月のリソース位置のプロトコル
2. Resource Naming
2. リソース命名
Although the resource location problem can, in most cases, be reduced to the problem of finding a host which implements a given Internet based protocol, locating only a particular lowest level Internet protocol (i.e. one assigned a protocol number for transport using IP) is not completely sufficient. Many significant network services and resources are provided through higher level protocols which merely utilize the various lower level protocols for their own transport purposes (e.g. the FTP protocol [2] employs the TCP protocol [4] for its lower level transport). Conceptually, this protocol nesting may even be carried out to arbitrary levels.
リソース位置問題は多くの場合ホストを見つけるという与えられたインターネットに基づいているプロトコルを実装する問題に減少できますが、特定の最も低い平らなインターネットプロトコル(すなわち、1つはIPを使用することで輸送のプロトコル番号を割り当てた)だけの場所を見つけるのは完全に十分であるというわけではありません。 単にそれら自身の輸送目的に様々な下のレベルプロトコルを利用するより高い平らなプロトコルを通して多くの重要なネットワーク・サービスとリソースを提供します(例えば、FTPプロトコル[2]は下のレベル輸送にTCPプロトコル[4]を使います)。 概念的に、このプロトコル巣篭もりが任意のレベルに行われさえするかもしれません。
Consequently, the Resource Location Protocol names a resource by the protocol number assigned to its lowest level Internet transport protocol and by a variable length protocol/resource specific identifier. For example, the UDP based Echo Protocol can be named by its assigned protocol number (17) and its assigned 16-bit "well-known" port number (7). Alternatively, the Internet Control Message Protocol [5] (lacking any higher level client protocols) would be named simply by its assigned protocol number (1) and an empty protocol specific identifier. On the other hand, some as yet undefined resource protocol (provided via say TCP), might be named by the assigned protocol number (6), its 16-bit "well-known" TCP port number, and then some additional fixed or variable length identifier specific to that TCP port.
その結果、Resource Locationプロトコルは最も低い平らなインターネットトランスポート・プロトコルに割り当てられたプロトコル番号と可変長プロトコル/リソースの特定の識別子でリソースを命名します。 例えば、割り当てられたプロトコル番号(17)とその割り当てられた16ビットの「よく知られる」ポートナンバー(7)でUDPのベースのEchoプロトコルを命名できます。 あるいはまた、インターネット・コントロール・メッセージ・プロトコル[5](どんなより高い平らなクライアントプロトコルも欠いています)は単に割り当てられたプロトコル番号(1)と空のプロトコル特定の識別子によって命名されるでしょう。 力が割り当てられたプロトコル番号(6)によって命名されて、16ビットの「よく知られる」TCPは他方では、まだ未定義のリソースとしての或るものが議定書を作って(言いたい事TCPを通して、提供します)、数を移植して、次に、そのTCPポートに特定の何らかの追加修理されたか可変な長さの識別子を移植します。
In general, the components of the protocol/resource specific identifier are defined to be the "natural" quantities used to successively de-multiplex the protocol at each next highest protocol level. See section 5 for some sample assignments.
一般に、プロトコル/リソースの特定の識別子の成分は、相次ぐ反-次のそれぞれの最も高いプロトコルレベルでプロトコルを多重送信するのに使用される「自然な」量になるように定義されます。 いくつかのサンプル課題に関してセクション5を見てください。
3. Protocol Summary
3. プロトコル概要
The Resource Location Protocol is a simple request/reply procedure. The querying host constructs a list of resources which it would like to locate and sends a request message on the network. A request message may be sent either to a particular IP address and host or, on networks which provide broadcast address capability, to the IP address which refers to all hosts on that network (see [7]). For example, a host attempting to locate a domain name server might construct a request containing the resource name [17, 53] (referring to the Domain Name Server protocol provided at "well-known" UDP port 53) and then broadcast that request on its local network.
Resource Locationプロトコルは簡単な要求/回答手順です。 質問しているホストは、それが場所を見つけたがっているリソースのリストを構成して、要求メッセージをネットワークに送ります。 特定のIPアドレスとホスト、または、そのネットワークのすべてのホストについて言及する放送演説能力を提供するネットワークに関するIPアドレスに要求メッセージを送るかもしれません。([7])を見てください。 例えば、ドメイン名サーバの場所を見つけるのを試みるホストは、リソース名[17、53](「よく知られる」UDPポート53で提供されたDomain Name Serverプロトコルを示します)を含む要求を構成して、次に、企業内情報通信網に関するその要求を放送するかもしれません。
Each receiving host examines the list of resources named in the request packet, determines which of the resources it provides, and returns a reply message to the querying host in confirmation. The receiving host determines whether or not it provides a resource by successive decomposition of the resource name until either the name is exhausted or it encounters a component which is not supported. In the previous
各受信ホストは、リクエスト・パケットで指定されたリソースのリストを調べて、それがリソースのどれを提供するかを決心して、確認で質問しているホストに応答メッセージを返します。 受信ホストは、それがリソース名の連続した分解で名前が疲れ果てているか、またはサポートされないコンポーネントに遭遇するまでリソースを提供するかどうかと決心しています。 前で
Accetta [Page 2] RFC 887 December 1983 Resource Location Protocol
Accetta[2ページ]RFC887 1983年12月のリソース位置のプロトコル
example, each host on the network receiving the broadcast request would examine the resource name by first consulting its tables to determine if it provided UDP service. If this was successful, it would then examine the UDP port component of the name and consult its UDP table to determine if it provided service on UDP port 53. At this point the name would be exhausted and if both checks were successful the host would return a reply message to the querying host indicating support for that resource.
例、放送要求を受け取るネットワークの各ホストはそれがサービスをUDPに供給したかどうか決定するためにテーブルに相談しながら、最初にでリソース名を調べるでしょう。 これがうまくいくなら、それは、次に、名前のUDPポートの部品を調べて、それがUDPポート53の上でサービスを提供したかどうか決定するためにUDPテーブルに相談するでしょうに。 ここに、名前は消耗するでしょう、そして、両方のチェックがうまくいくなら、ホストはそのリソースのサポートを示す質問しているホストに応答メッセージを返すでしょうに。
3.1. Request Messages
3.1. 要求メッセージ
RLP provides two basic types of request messages which may be transmitted by a querying host. The first type requires any host receiving the request message to return a reply message only if it provides at least one of the resources named in the request list. The second type requires any host receiving the message to always return a reply message even if it provides none of the resources named in the request list.
RLPは質問しているホストによって伝えられるかもしれない2人の基本型の要求メッセージを提供します。 最初のタイプは少なくとも要求リストで指定されたリソースの1つを提供する場合にだけ応答メッセージを返す要求メッセージを受け取るホストを必要とします。 2番目のタイプは要求リストで指定されたリソースのいずれも提供しないでもいつも応答メッセージを返すメッセージを受け取るホストを必要とします。
These two types of request messages are:
これらの2つのタイプに関する要求メッセージは以下の通りです。
<Who-Provides?>
This type requires any host receiving the message to return an
appropriate reply message which names all of the resources from the
request list which it provides. If the receiving host provides none
of the named resources, no reply may be returned.
<、だれ、-、提供、--これがタイプする>はそれが提供する要求リストからリソースのすべてを命名する適切な応答メッセージを返すメッセージを受け取るホストを必要とします。 受信ホストが命名されたリソースのいずれも提供しないなら、回答を全く返さないかもしれません。
<Do-You-Provide?>
This type is identical to the <Who-Provides?> message but with the
extra requirement that a reply must always be returned. When a
receiving host provides none of the requested resources, it simply
returns an empty reply list. This empty reply list allows the
querying host to immediately detect that the confirming host
provides none of the named resources without having to timeout after
repeatedly retransmitting the request.
<、あなたが提供する、-->メッセージをWho提供しますが、回答がいつもあるに違いないという付加的な要件と共に返すのを除いて、これがタイプする>は<と同じです。 受信ホストが要求されたリソースのいずれも提供しないとき、それは単に空の回答リストを返します。 繰り返して要求を再送した後に、この空の回答リストはタイムアウトへの有なしですぐに検出する確認しているホストが提供する質問しているホストに命名されたリソースのいずれも許容しません。
The <Who-Provides?> request message is most typically used when broadcasting requests to an entire IP network. The <Do-You-Provide?> request message, on the other hand, is most typically used when confirming that a particular host does or does not provide one or more specific resources. It may not be broadcast (since such a request would flood the querying host with reply messages from all hosts on the network).
<はWho提供されます--全体のIPネットワークに要求を放送するとき、>要求メッセージは最も通常使用されます。 <Do、-、あなた、-提供してください--特定のホストがするか、または1つ以上の特定のリソースを提供しないと確認するとき、他方では、>要求メッセージは最も通常使用されます。 それは放送されないかもしれません(そのような要求が応答メッセージでネットワークのすべてのホストから質問しているホストをあふれさせるでしょう、したがって)。
In addition to the two basic types of request messages, an additional two variant types of request messages may also be transmitted by a querying host. These message types provide a "third-party" resource location capability. They differ from the basic message types by
また、2人の基本型の要求メッセージに加えて、追加2人の異型の要求メッセージは質問しているホストによって伝えられるかもしれません。 これらのメッセージタイプは「第三者」リソース位置の能力を提供します。 彼らはメッセージがタイプする基本的と異なっています。
Accetta [Page 3] RFC 887 December 1983 Resource Location Protocol
Accetta[3ページ]RFC887 1983年12月のリソース位置のプロトコル
providing space for an additional qualifier with each listed resource to identify "third-party" hosts which the confirming host believes may provide the resource. As before, the first type requires any host receiving the request message to return a reply message only if it knows of some host which provides at least one of the resources named in the request list. The second type requires any host receiving the message to always return a reply message even if it knows of no hosts which provide any of the resources named in the request list.
「第三者」ホストを特定する確認しているホストが信じているそれぞれの記載されたリソースを追加資格を与える人のためのスペースに提供すると、リソースは提供されるかもしれません。 従来と同様、最初のタイプはホストを知っている場合にだけ応答メッセージを返す要求メッセージを受け取るホストを必要とします(少なくとも要求リストで指定されたリソースの1つを提供します)。 2番目のタイプはホストを全く知らないでもいつも応答メッセージを返すメッセージを受け取るホストを必要とします(要求リストで指定されたリソースのどれかを提供します)。
These two remaining types of request messages are:
これらの2つの残っているタイプに関する要求メッセージは以下の通りです。
<Who-Anywhere-Provides?>
This message parallels the <Who-Provides?> message with the
"third-party" variant described above. The confirming host is
required to return at least its own IP address (if it provides the
named resource) as well as the IP addresses of any other hosts it
believes may provide the named resource. The confirming host
though, may never return an IP address for a resource which is the
same as an IP address listed with the resource name in the request
message. In this case it must treat the resource as if it was
unsupported at that IP address and omit it from any reply list.
どこでも提供する<?これが<が「第三者」異形が説明されている>メッセージをWho提供する平行線を通信させる>。 確認しているホストはそれが命名されたリソースを提供するかもしれないと信じているいかなる他のホストのIPアドレスと同様に少なくともそれ自身のIPアドレスを返さなければなりません(命名されたリソースを提供するなら)。 確認が接待する、もっとも、リソース名が要求メッセージにある状態でIPアドレスが記載したように同じであるリソースのためのIPアドレスを決して返さないかもしれません。 この場合、それは、まるでそれがそのIPアドレスでサポートされないかのようにリソースを扱って、どんな回答リストからもそれを省略しなければなりません。
<Does-Anyone-Provide?>
This message parallels the <Do-You-Provide?> message again with the
"third-party" variant described above. As before, the confirming
host is required to return its own IP address as well as the IP
addresses of any other hosts it believes may provide the named
resource and is prohibited from returning the same IP address in the
reply resource specifier as was listed in the request resource
specifier. As in the <Do-You-Provide?> case and for the same
reason, this message also may not be broadcast.
<、だれでも提供する、--これが通信させる>が<Doに沿う、-、あなた、-提供してください--再び「第三者」異形が上で説明されている>メッセージ。 従来と同様、確認しているホストは、それが命名されたリソースを提供するかもしれないと信じているいかなる他のホストのIPアドレスと同様にそれ自身のIPアドレスを返すのが必要であり、要求リソース特許説明書の作成書に記載された回答リソース特許説明書の作成書で同じ戻っているIPアドレスから禁じられます。 <Do、-、あなた、-提供してください-->ケースと同じ理由で、このメッセージも放送されないかもしれません。
These variant request messages permit "smart" hosts to supply resource location information for networks without broadcast capability (provided that all hosts on the network always "know" the address of one or more such "smart" hosts). They also permit resource location information for services which are not provided anywhere on a directly connected network to be provided by "smart" gateways which have perhaps queried other networks to which they are attached or have somehow otherwise acquired the information.
これらの異形要求メッセージは、「賢い」ホストが放送能力なしでネットワークのためのリソース位置情報を提供することを許可します(ネットワークのすべてのホストがいつもそのようなホストの「賢い」より多くのひとりのアドレスを「知っていれ」ば)。 また、彼らは恐らく、それらが付けている他のネットワークについて質問したか、またはそうでなければどうにか情報を取得した「賢い」ゲートウェイによって提供される直接接続されたネットワークで何処にも提供されないサービスのためのリソース位置情報を可能にします。
The restriction against returning the same IP address in a reply as was specified in the request provides a primitive mechanism for excluding certain known addresses from consideration in a reply (see section 5, example 3). It may also be used to override the receiving host's preference for its own IP address in "third-party" replies when this is required.
要求で指定された回答で同じIPアドレスを返すことに対する制限はある知られているアドレスを回答における考慮に入れないようにするのに原始のメカニズムを提供します(セクション5を見てください、例3)。 また、それは、これが必要であるときに、「第三者」回答におけるそれ自身のIPアドレスのために受信ホストの好みをくつがえすのに使用されるかもしれません。
Accetta [Page 4] RFC 887 December 1983 Resource Location Protocol
Accetta[4ページ]RFC887 1983年12月のリソース位置のプロトコル
3.2. Reply Messages
3.2. 応答メッセージ
Each of the types of request messages has an associated type of reply message. The basic reply message type is returned in response to both <Who-Provides?> and <Do-You-Provide?> request messages and supplies information about the resources provided by the confirming host. The other reply message type is the "third-party" variant returned in response to both <Who-Anywhere-Provides?> and <Does-Anyone-Provide?> request messages and supplies information about resources provided by hosts known to the confirming host.
要求メッセージのタイプ各人には、関連タイプに関する応答メッセージがあります。 <が>と<DoをWho提供する両方に対応して基本的な応答メッセージタイプを返す、-、あなた、-提供してください-->要求は、確認しているホストで調達資金の情報を通信して、提供します。 もう片方の応答メッセージタイプが異形が両方に対応してどこでも<Whoを返した「第三者」である、-、>と<Doesを提供する、-、だれ、も-提供してください-->要求は、確認しているホストにとって知られているホストで、調達資金の情報を通信して、提供します。
These two types of reply messages are:
これらの2つのタイプに関する応答メッセージは以下の通りです。
<I-Provide>
This reply message contains a list of exactly those resources from
the request list which the confirming host provides. These
resources must occur in the reply list in precisely the same order
as they were listed in the request message.
<は確認しているホストが提供する要求リストからのまさにそれらのリソースのリストを応答メッセージが含む>ThisにIで供給します。 それらが要求メッセージに記載されたようにこれらのリソースは回答リストに正確に同次で現れなければなりません。
<They-Provide>
This reply message similarly contains a list of exactly those
resources from the request list (appropriately qualified with IP
addresses) which the confirming host provides or believes another
host provides. These resources again must occur in the reply list
in precisely the same order as they were listed in the request
message.
<、それら、-まさにそれらのリソースのリストを確認しているホストが、前提とするか、または別のホストが提供すると信じている要求リスト(適切に、IPアドレスで、資格を得る)から応答メッセージが同様に含む>Thisに供給してください。 それらが要求メッセージに記載されたようにこれらのリソースは再び回答リストに正確に同次で現れなければなりません。
Neither type of reply message may be broadcast.
どちらのタイプに関する応答メッセージは放送されるかもしれません。
A querying host which receives a <They-Provide> reply message from a confirming host on behalf of a third host is not required to unquestioningly rely on the indirectly provided information. This information should usually be regarded simply as a hint. In most cases, the querying host should transmit a specific <Do-You-Provide?> request to the third host and confirm that the resource is indeed provided at that IP address before proceeding.
<を受け取るホストについて質問すると3番目のホストを代表した確認しているホストからの>応答メッセージがThey提供されるAは、何の疑問も抱かずに間接的に提供された情報を当てにするのに必要ではありません。 通常、この情報は単にヒントと見なされるべきです。 -第3代ホストに>要求を前提としてください、そして、本当に、リソースが進行の前にそのIPアドレスで提供されると確認してください。
4. Message Formats
4. メッセージ・フォーマット
RLP messages are encapsulated in UDP packets to take advantage of the multiplexing capability provided by the UDP source and destination ports and the extra reliability provided by the UDP checksum. Request messages are sent from a convenient source port on the querying host to the assigned RLP destination port of a receiving host. Reply messages are returned from the assigned RLP source port of the confirming host to the appropriate destination port of the querying host as determined by the source port in the request message.
RLPメッセージは、UDPソースと仕向港によって提供されたマルチプレクシング能力とUDPチェックサムによって提供された付加的な信頼性を利用するためにUDPパケットでカプセル化されます。 質問しているホストの上の便利なソースポートから割り当てられた受信ホストのRLP仕向港に要求メッセージを送ります。 要求メッセージのソースポートで決定するように確認しているホストの割り当てられたRLPソースポートから適切な質問しているホストの仕向港まで応答メッセージを返します。
The format of the various RLP messages is described in the following diagrams. All numeric quantities which occupy more than one octet are
様々なRLPメッセージの形式は以下のダイヤグラムで説明されます。1つ以上の八重奏を占領するすべての数値量がそうです。
Accetta [Page 5] RFC 887 December 1983 Resource Location Protocol
Accetta[5ページ]RFC887 1983年12月のリソース位置のプロトコル
stored in the messages from the high order octet to the low order octet as per the usual Internet protocol standard. All packet diagrams indicate the octets of the message from left to right and then top to bottom as they occur in the data portion of the encapsulating UDP packet.
メッセージでは、普通のインターネットプロトコル標準に従って高位八重奏から下位の八重奏まで保存されます。 要約のUDPパケットのデータ部に起こるとき、すべてのパケットダイヤグラムが左から右と次に、先端から下部までメッセージの八重奏を示します。
Each RLP packet has the general format
それぞれのRLPパケットには、一般形式があります。
+--------+--------+--------+--------+
| | | |
| Type | Flags | Message-ID |
| | | |
+--------+--------+--------+--------+
| -
| Resource-List -
| -
+--------+--------+--------+---\\---+
- +
- Resource-List |
- |
+--------+--------+--------+---\\---+
+--------+--------+--------+--------+ | | | | | タイプ| 旗| Message ID| | | | | +--------+--------+--------+--------+ | - | リソースリスト、-| - +--------+--------+--------+---\\---+--+--リソースリスト| - | +--------+--------+--------+---\\---+
where
どこ
<Type>
is a single octet which identifies the message type. The currently
defined types are:
<タイプ>はメッセージタイプを特定するただ一つの八重奏です。 現在定義されたタイプは以下の通りです。
0 <Who-Provides?>
1 <Do-You-Provide?>
2 <Who-Anywhere-Provides?>
3 <Does-Anyone-Provide?>
4 <I-Provide>
5 <They-Provide>
6-255 Reserved.
0、<、だれ、-、提供、-->1、<、あなたが提供する、--どこでも提供する>2<?>3、<、だれでも提供する、-->4<が>5<をIで提供する、それら、-6-255が予約した>を提供してください。
Accetta [Page 6] RFC 887 December 1983 Resource Location Protocol
Accetta[6ページ]RFC887 1983年12月のリソース位置のプロトコル
<Flags>
is a single octet specifying possible modifications to the standard
interpretation of <Type>. Bits in this field are numbered from left
to right (from most significant to least significant) beginning with
bit 1. The currently defined flag bits are:
<旗の>は<Type>の標準の解釈への可能な変更を指定するただ一つの八重奏です。 この分野のビットは、ビット1で始まりながら、左から右(最も重要であるのから最も重要にならないまでの)まで付番されます。 現在定義されたフラグビットは以下の通りです。
Bit 1 <Local-Only>. Requires that any reply message generated in
response to a request message with this flag bit set may
only name IP addresses which are on the same IP network as
the sender of the request message. This flag also requires
that multi-homed hosts answering broadcast <Who-Provides?>
requests use the appropriate local network IP source
address in the returned reply. This bit must be zero in
reply messages.
Bits 2-8 Reserved. Must be zero.
1<に噛み付いて、唯一>にしました地方の。 このフラグビットがセットしたことでの要求メッセージに対応して生成されたどんな応答メッセージも要求メッセージの送付者と同じIPネットワークにあるIPアドレスを命名するだけであるかもしれないのが必要です。 また、この旗がそれを必要とする、マルチ、家へ帰り、放送<に答えるとWho提供されるホスト-->要求は返された回答に適切な企業内情報通信網IPソースアドレスを使用します。 このビットは応答メッセージのゼロであるに違いありません。 2-8が予約したビット。 ゼロにならなければならなくなってください。
<Message-ID>
is a two octet (16-bit) value which identifies the request message.
It is used simply to aid in matching requests with replies. The
sending host should initialize this field to some convenient value
when constructing a request message. The receiving host must return
this same value in the <Message-ID> field of any reply message
generated in response to that request.
<Message ID>は要求メッセージを特定する2八重奏(16ビット)値です。 それは、単に回答で合っている要求で支援するのに使用されます。 要求メッセージを構成するとき、送付ホストは何らかの便利な値にこの分野を初期化するべきです。 受信ホストはMessage-ID>がさばくその要求に対応して生成されたどんな応答メッセージの<でもこの同じ値を返さなければなりません。
<Resource-List>
is the list of resources being queried or for which location
information is being supplied. This list is a sequence of octets
beginning at the octet following the <Message-ID> and extending
through the end of the UDP packet. The format of this field is
explained more fully in the following section. The size of this
list is implicitly specified by the length of the encapsulating UDP
datagram.
<リソースリスト>を質問されるリソースのリストであるかどの位置情報に供給しているか。 このリストは<Message-ID>に続いて、UDPパケットの端まで広がる八重奏のときに始まる八重奏の系列です。 この分野の書式は以下のセクションで、より完全に説明されます。 このリストのサイズは要約のUDPデータグラムの長さによってそれとなく指定されます。
4.1. Resource Lists
4.1. リソースリスト
A <Resource-List> consists of zero or more resource specifiers. Each resource specifier is simply a sequence of octets. All resource specifiers have a common resource name initial format
<Resource-リスト>はゼロか、より多くのリソース特許説明書の作成書から成ります。 それぞれのリソース特許説明書の作成書は単に八重奏の系列です。 すべてのリソース特許説明書の作成書で、一般的なリソースは初期の形式を命名します。
+--------+--------+--------+---\\---+
| | | |
|Protocol|IDLength| Resource-ID |
| | | |
+--------+--------+--------+---\\---+
+--------+--------+--------+---\\---+ | | | | |プロトコル|IDLength| Resource ID| | | | | +--------+--------+--------+---\\---+
where
どこ
Accetta [Page 7] RFC 887 December 1983 Resource Location Protocol
Accetta[7ページ]RFC887 1983年12月のリソース位置のプロトコル
<Protocol>
is the protocol number assigned to the lowest level Internet
protocol utilized for accessing the resource.
<プロトコル>はリソースにアクセスするのに利用される中で最も低い平らなインターネットプロトコルに割り当てられたプロトコル番号です。
<IDLength>
is the length of the resource identifier associated with this
<Protocol>. This length may be a fixed or variable value depending
on the particular resource. It is included so that specifiers which
refer to resources which a host may not provide can be skipped over
without needing to know the specific structure of the particular
resource identifier. If the <Protocol> has no associated natural
identifier, this length is 0.
<IDLength>はこの<プロトコル>に関連しているリソース識別子の長さです。 この長さは特定のリソースに依存する修理されたか可変な値であるかもしれません。 それは、特定のリソース識別子の特定の構造を知る必要はなくてホストが提供しないかもしれないリソースを示す特許説明書の作成書を飛ばすことができるように含まれています。 <プロトコル>にどんな関連自然な識別子もないなら、この長さは0です。
<Resource-ID>
is the qualifying identifier used to further refine the resource
being queried. If the <IDLength> field was 0, then this field is
empty and occupies no space in the resource specifier.
<Resource ID>はさらに質問されるリソースを洗練するのに使用される資格を得る識別子です。 <IDLength>分野が0であったなら、この分野は、空であり、リソース特許説明書の作成書でスペースを全く占めません。
In addition, resource specifiers in all <Who-Anywhere-Provides?>, <Does-Anyone-Provide?> and <They-Provide> messages also contain an additional qualifier following the <Protocol-ID>. This qualifier has the format
追加、どこでもすべての<Whoのリソース特許説明書の作成書、-、>、<Doesが提供する、-、だれ、も-提供してください--<Protocol ID>に続いて、>と<はまたメッセージが含む>に追加資格を与える人をThey供給します。 この資格を与える人には、形式があります。
+--------+--------+--------+--------+---//---+
| | |
|IPLength| IP-Address-List |
| | |
+--------+--------+--------+--------+---//---+
+--------+--------+--------+--------+---//---+ | | | |IPLength| IP-住所録| | | | +--------+--------+--------+--------+---//---+
where
どこ
Accetta [Page 8] RFC 887 December 1983 Resource Location Protocol
Accetta[8ページ]RFC887 1983年12月のリソース位置のプロトコル
<IPLength>
is the number of IP addresses containing in the following
<IP-Address-List> (the <IP-Address-List> field thus occupies the
last 4*<IPLength> octets in its resource specifier). In request
messages, this is the maximum number of qualifying addresses which
may be included in the corresponding reply resource specifier.
Although not particularly useful, it may be 0 and in that case
provides no space for qualifying the resource name with IP addresses
in the returned specifier. In reply messages, this is the number of
qualifying addresses known to provide the resource. It may not
exceed the number specified in the corresponding request specifier.
This field may not be 0 in a reply message unless it was supplied as
0 in the request message and the confirming host would have returned
one or more IP addresses had any space been provided.
<IPLength>は以下の<IP-アドレスリストに>を含むIPアドレスの数(その結果IP-アドレスリスト>がさばく<はリソース特許説明書の作成書でベスト4*<IPLength>八重奏を占領する)です。 要求メッセージでは、これは対応する回答リソース特許説明書の作成書に含まれるかもしれない資格を得るアドレスの最大数です。 特に役に立ちませんが、それは、0であるかもしれなく、その場合返された特許説明書の作成書でIPアドレスのリソース名に資格を与えるのにスペースを全く提供しません。 応答メッセージでは、これはリソースを提供するのが知られている資格を得るアドレスの数です。 それは対応する要求特許説明書の作成書で指定された数を超えないかもしれません。 何かスペースを提供したなら要求メッセージと確認しているホストの0が1つ以上のIPアドレスを返したようにそれが供給されなかったなら、この分野は応答メッセージの0でないかもしれません。
<IP-Address-List>
is a list of four-octet IP addresses used to qualify the resource
specifier with respect to those particular addresses. In reply
messages, these are the IP addresses of the confirming host (when
appropriate) and the addresses of any other hosts known to provide
that resource (subject to the list length limitations). In request
messages, these are the IP addresses of hosts for which resource
information may not be returned. In such messages, these addresses
should normally be initialized to some "harmless" value (such as the
address of the querying host) unless it is intended to specifically
exclude the supplied addresses from consideration in any reply
messages.
<IP-アドレスリスト>はそれらの特定のアドレスに関してリソース特許説明書の作成書に資格を与えるのに使用される4八重奏のIPアドレスのリストです。 応答メッセージでは、これらは、確認のアドレスが接待する(適切であるときに)IPとそのリソース(リスト長さの制限を条件とした)を提供するのが知られているいかなる他のホストのアドレスです。 要求メッセージでは、これらはリソース情報が返されないかもしれないホストのIPアドレスです。 そのようなメッセージでは、明確にどんな応答メッセージでも考慮に供給されたアドレスを入れないようにするのが意図していない場合、通常、これらのアドレスは何らかの「無害な」値(質問しているホストのアドレスなどの)に初期化されるはずです。
The receiving host determines if it provides any of the resources named in the request list by successively decomposing each resource name. The first level of decomposition is the Internet protocol number which can presumably be looked up in a table to determine if that protocol is supported on the host. Subsequent decompositions are based on previous components until one of three events occur:
受信ホストは、それぞれのリソース名を分解しながら、それが要求リストで相次ぐことによって指定されたリソースのどれかを提供するかどうかと決心しています。 最初のレベルの分解はおそらく、そのプロトコルがホストの上でサポートされるかどうか決定するためにテーブルで調べることができるインターネットプロトコル番号です。 その後の分解は前の3の1つ時までのコンポーネントに基づいてイベントが起こるということです:
1. the current component identifies some aspect of the previous
components which the host does not support,
1. 現在のコンポーネントはホストがサポートしない前のコンポーネントの何らかの局面を特定します。
2. the resource name from the request list is exhausted, or
または2. 要求リストからのリソース名が疲れ果てている。
3. the resource name from the request list is not exhausted but
the host does not expect any further components in the name
given the previous components
3. 要求リストからのリソース名は疲れ果てていませんが、前のコンポーネントを考えて、ホストは名前のどんなさらなるコンポーネントも予想しません。
In case 1, the receiving host has determined that it does not provide the named resource. The resource specifier may not be included in any reply message returned.
場合1では、受信ホストは、命名されたリソースを提供しないと決心していました。 リソース特許説明書の作成書は返されたどんな応答メッセージにも含まれないかもしれません。
In case 2, the receiving host has determined that it does indeed provide the named resource (note: this may occur even if the receiving host
場合2では、受信ホストが、本当に、命名されたリソースを提供すると決心していた、(注意: これが起こるかもしれない、受信ホスト
Accetta [Page 9] RFC 887 December 1983 Resource Location Protocol
Accetta[9ページ]RFC887 1983年12月のリソース位置のプロトコル
would have expected the resource name to contain more components than were actually present). The resource specifier must be included (modulo IP address prohibitions) in any reply message returned.
リソース名が実際にプレゼントより多くのコンポーネントを含むと予想しただろう、) 返されたどんな応答メッセージにもリソース特許説明書の作成書を含まなければなりません(法IPアドレス禁止)。
In case 3, the receiving host has determined that it does not completely provide the named resource since name components remain which it does not understand (this might occur with specializations of or extensions to a known protocol which are not universally recognized). The resource specifier may not be included in any reply message returned.
3、受信ホストが、完全に命名されたリソースを提供するというわけではないと決心していて、名前コンポーネントがどれを残していて、それは分かりません(これは知られているプロトコルへの一般に認識されない専門化か拡大で起こるかもしれません)。 リソース特許説明書の作成書は返されたどんな応答メッセージにも含まれないかもしれません。
5. Sample Usage
5. サンプル用法
The following scenarios illustrate some typical uses of RLP. In all cases the indicated messages are encapsulated in a UDP datagram with the appropriate source and destination port numbers, message length, and checksum. This datagram is further encapsulated in an IP datagram with the appropriate source address of the sending host and destination address (either broadcast or individual) for the receiving host.
以下のシナリオはRLPのいくつかの典型的な用途を例証します。 すべての場合では、示されたメッセージはUDPデータグラムで適切なソース、目的地ポートナンバー、メッセージ長、およびチェックサムでカプセル化されます。 このデータグラムは受信ホストのためにIPデータグラムで送付ホストと送付先アドレスの適切なソースアドレスでカプセル化された状態で(放送されたか、個々の)より遠いです。
All numeric protocol examples are as specified in the appropriate protocol description documents listed in the references.
すべての数値プロトコルの例が参照にリストアップされた適切なプロトコル記述ドキュメントで指定されるようにあります。
1. Suppose a freshly rebooted host H wishes to find some gateway
on its directly connected network to which it can send its
first external packet. It then broadcasts the request
1. 新たにリブートされたホストHがそれが最初の外部のパケットを送ることができる直接接続されたネットワークのあるゲートウェイを見つけたがっていると仮定してください。 そして、それは要求を放送します。
<Who-Provides?> <Flags>=<Local-Only> <Message-ID>=12345
<Resource-List>={[GGP], [EGP]}
<、だれ、-、提供、--><は12345<リソースリスト<地方に唯一の><Message>=ID>=>=に旗を揚げさせます。[GGP]、[EGP]
encoded as the 8 octet message
8八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 128 | 12345 | 3 | 0 | 8 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 128 | 12345 | 3 | 0 | 8 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+
on its local network.
企業内情報通信網に関して。
- Gateway G1 (which understands EGP) receives the request and
returns the reply
- ゲートウェイG1(EGPを理解している)は要求を受け取って、回答を返します。
<I-Provide> <Flags>=none <Message-ID>=12345
<Resource-List>={[EGP]}
<はID>= 12345を通信させている<<リソースリスト>=を><旗の>=なにもにIで提供しません。[EGP]
encoded as the 6 octet message
6八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+-----+-----+
| 4 | 0 | 12345 | 8 | 0 |
+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+ | 4 | 0 | 12345 | 8 | 0 | +-----+-----+-----+-----+-----+-----+
to host H which then remembers that gateway G1 may be used
次にそのゲートウェイG1を覚えているHを接待するのは使用されているかもしれません。
Accetta [Page 10] RFC 887 December 1983 Resource Location Protocol
Accetta[10ページ]RFC887 1983年12月のリソース位置のプロトコル
to route traffic to the rest of the Internet.
インターネットの残りにトラフィックを発送するために。
- At the same time, gateway G2 (which understands both GGP
and EGP) might also receive the request and return the reply
- 同時に、ゲートウェイG2(GGPとEGPの両方を理解している)はまた、要求を受け取って、回答を返すかもしれません。
<I-Provide> <Flags>=none <Message-ID>=12345
<Resource-List>={[GGP], [EGP]}
<はID>= 12345を通信させている<<リソースリスト>=を><旗の>=なにもにIで提供しません。[GGP]、[EGP]
encoded as the 8 octet message
8八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+-----+-----+-----+-----+
| 4 | 0 | 12345 | 3 | 0 | 8 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | 4 | 0 | 12345 | 3 | 0 | 8 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+
to host H which might then also add gateway G2 to its list
if it chooses.
また、ホストHに、選ぶなら、どれがそしてときにそうするかもしれないかはゲートウェイG2をリストに追加します。
2. Assume instead that host H is a stand-alone system which has
just encountered some fatal software error and wishes to locate
a crash dump server to save its state before reloading.
Suppose that the crash dump protocol on the host's local
network is implemented using the Trivial File Transfer Protocol
(TFTP) [8]. Furthermore, suppose that the special file name
"CRASH-DUMP" is used to indicate crash dump processing (e.g.
the server might locally generate a unique file name to hold
each dump that it receives from a host). Then host H might
broadcast the request
2. 代わりにホストHがちょうど何らかの致命的なソフトウェア誤りに遭遇して、再び荷を積む前に状態を節約するために速成のダンプサーバの場所を見つけたがっているスタンド・アローン・システムであると、仮定してください。 ホストの企業内情報通信網の速成のダンププロトコルがトリビアル・ファイル転送プロトコル(TFTP)[8]を使用することで実装されると仮定してください。 その上、「速成のダンプ」という特別なファイル名が速成のダンプ処理を示すのに使用されると仮定してください(例えば、サーバはそれが受ける各ダンプをホストから隠すために局所的にユニークなファイル名を生成するかもしれません)。 そして、ホストHは要求を放送するかもしれません。
<Who-Provides?> <Flags>=none <Message-ID>=54321
<Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}
<、だれ、-、提供、--><が54321<Message ID>=<がリソースで記載しない>=なにも旗を揚げさせる、>は等しいです。[UDP、TFTP、WRQ、「速成のダンプ」]
encoded as the 21 octet message
21八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 0 | 54321 | 17 | 15 | 69 |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | 'C' 'R' 'A' 'S' 'H' '-' |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 'D' 'U' 'M' 'P' 0 |
+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 0 | 54321 | 17 | 15 | 69 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 2 | 'C''R''''s''H''--'| +-----+-----+-----+-----+-----+-----+-----+-----+ | '、''U'は''P'0でしょう。| +-----+-----+-----+-----+-----+
to its local network (note that the file name component is
explicitly terminated by a null so as not to exclude future
further specialization of the crash dump protocol).
企業内情報通信網(ファイル名コンポーネントが速成のダンププロトコルのさらなる今後の専門化を除かないようにヌルによって明らかに終えられることに注意する)に。
- Host C (which supports this specialization of the TFTP
protocol) receives the request and returns the reply
- ホストC(TFTPプロトコルのこの専門化をサポートします)は、要求を受け取って、回答を返します。
<I-Provide> <Flags>=none <Message-ID>=54321
<Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}
<はID>= 54321を通信させている<<リソースリスト>=を><旗の>=なにもにIで提供しません。[UDP、TFTP、WRQ、「速成のダンプ」]
Accetta [Page 11] RFC 887 December 1983 Resource Location Protocol
Accetta[11ページ]RFC887 1983年12月のリソース位置のプロトコル
encoded as the 21 octet message
21八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+-----+-----+-----+-----+
| 4 | 0 | 54321 | 17 | 15 | 69 |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | 'C' 'R' 'A' 'S' 'H' '-' |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 'D' 'U' 'M' 'P' 0 |
+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | 4 | 0 | 54321 | 17 | 15 | 69 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 2 | 'C''R''''s''H''--'| +-----+-----+-----+-----+-----+-----+-----+-----+ | '、''U'は''P'0でしょう。| +-----+-----+-----+-----+-----+
to host H which may then proceed to send its crash dump to
host C and reload.
次にクラッシュを送るかもしれなくしかけるHを接待するために、ホストCにどさっと落としてください、そして、再び荷を積んでください。
- Host D (which provides TFTP service but not the crash dump
specialization), however, might receive the request and
determine that it provides no support for the resource
(since the resource name contains components following the
UDP port number which it does not understand). It would
therefore return no reply to host H.
- しかしながら、ホストD(速成でないダンプ専門化だけをTFTPサービスに提供します)は、要求を受け取って、リソースのサポートを全く提供しないと決心するかもしれません(それが理解していないUDPポートナンバーに続いて、リソース名がコンポーネントを含んでいるので)。 したがって、それは回答を全くホストHに返さないでしょう。
3. Finally, suppose host M wishes to locate some domain name
translation server (either UDP or TCP based) anywhere on the
Internet. Furthermore, suppose that host M is on a IP network
which does not provide broadcast address capabilities and that
host R is a "known" resource location server for that network.
3. 最終的に、ホストMがインターネットでどこでも何らかのドメイン名翻訳サーバ(UDPかTCPが基礎づけたどちらか)の場所を見つけたがっていると仮定してください。 その上、ホストMが放送演説能力を提供しないIPネットワークの一員であり、ホストRがそのネットワークのための「知られている」リソース位置のサーバであると仮定してください。
First, since host M prefers to find a domain name server on its
own locally connected network if possible, it sends the request
ホストMが、できれば、それ自身の局所的に接続されたネットワークでドメイン名サーバを見つけるのを好むので、まず最初に、それは要求を送ります。
<Does-Anyone-Provide?> <Flags>=<Local-Only>
<Message-ID>=12321 <Resource-List>=
{[TCP, <DOMAIN-NAME-SERVER-PORT>] {M},
[UDP, <DOMAIN-NAME-SERVER-PORT>] {M}}
<、だれでも提供する、--><は12321<リソースリスト<地方に唯一の><Message>=ID>=>=に旗を揚げさせます。[TCP、<ドメイン名サーバポート>]M、[UDP、<ドメイン名サーバポート>]M
encoded as the 22 octet message
22八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+
| 3 | 128 | 12321 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 2 | 53 | 1 | M |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 17 | 2 | 53 | 1 | M |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+ | 3 | 128 | 12321 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 6 | 2 | 53 | 1 | M| +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 17 | 2 | 53 | 1 | M| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
to host R.
ホストRに。
Host R receives the request and consults its tables for any
hosts known to support either variety of domain name service.
It finds entries indicating that both hosts S and T provide UDP
ホストRは、どちらかの種類のドメイン名サービスをサポートするのが知られているどんなホストのためにも、要求を受け取って、テーブルに相談します。 それは、エントリーが、ホストSとTの両方がUDPを提供するのを示しているのがわかります。
Accetta [Page 12] RFC 887 December 1983 Resource Location Protocol
Accetta[12ページ]RFC887 1983年12月のリソース位置のプロトコル
based domain name service but that neither host is on the same
IP network as host H. It must then send the negative
confirmation reply
どちらのホストが次に、ホストH.Itが消極的確認回答を送らなければならないような同じIPネットワークの一員でなかったならドメイン名サービスを基礎づけます。
<They-Provide> <Flags>=none <Message-ID>=12321
<Resource-List>={}
<、それら、-ID>= 12321を通信させている<<リソースリスト>=を><旗の>=なにもに提供しないでください。{}
encoded as the 4 octet message
4八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+
| 5 | 0 | 12321 |
+-----+-----+-----+-----+
+-----+-----+-----+-----+ | 5 | 0 | 12321 | +-----+-----+-----+-----+
back to host M.
ホストMに。
Host M, receiving this reply, might now abandon any hope of
finding a server on its own network, reformat its request to
permit any host address, and resend
この回答を受け取って、ホストMは現在、それ自身のネットワーク、再フォーマットに関するサーバがどんなホストも可能にするという要求であることがわかるという望みが扱って、再送するいずれも捨てるかもしれません。
<Does-Anyone-Provide?> <Flags>=none <Message-ID>=12322
<Resource-List>=
{[TCP, <DOMAIN-NAME-SERVER-PORT>] {M},
[UDP, <DOMAIN-NAME-SERVER-PORT>] {M}}
<、だれでも提供する、--><が12322<Message ID>=<がリソースで記載しない>=なにも旗を揚げさせる、>は等しいです。[TCP、<ドメイン名サーバポート>]M、[UDP、<ドメイン名サーバポート>]M
encoded as the 22 octet message
22八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+
| 3 | 0 | 12322 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 2 | 53 | 1 | M |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 17 | 2 | 53 | 1 | M |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+ | 3 | 0 | 12322 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 6 | 2 | 53 | 1 | M| +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 17 | 2 | 53 | 1 | M| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
again to host R.
再びホストRに。
Host R receives this new request and is no longer constrained
to return only local addresses. However, since only space for
a single qualifying IP address was provided in each request
resource specifier, it may not immediately return both
addresses. Instead, it is forced to return only the first
address and replies
ホストRは、この新しい要求を受け取って、もうローカルのアドレスだけを返すのが抑制されません。 しかしながら、IPアドレスに資格を与えるシングルのための唯一のスペースをそれぞれの要求リソース特許説明書の作成書に提供したので、それはすぐに、両方のアドレスを返さないかもしれません。 代わりに、最初のアドレスと回答だけを返すのは無理矢理であっています。
<They-Provide> <Flags>=none <Message-ID>=12322
<Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {S}}
<、それら、-ID>= 12322を通信させている<<リソースリスト>=を><旗の>=なにもに提供しないでください。[UDP、<ドメイン名サーバポート>]S
encoded as the 13 octet message
13八重奏メッセージとして、コード化されます。
Accetta [Page 13] RFC 887 December 1983 Resource Location Protocol
Accetta[13ページ]RFC887 1983年12月のリソース位置のプロトコル
+-----+-----+-----+-----+-----+-----+-----+-----+
| 5 | 0 | 12322 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | S |
+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | 5 | 0 | 12322 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | S| +-----+-----+-----+-----+-----+
to Host M.
ホストMに。
Host M receives the reply and (being the suspicious sort)
decides to confirm it with host S. It then sends
ホストMは回答を受け取ります、そして、(疑わしげな種類です)は次にItが送るホストS.と共にそれを確認すると決めます。
<Do-You-Provide?> <Flags>=none <Message-ID>=12323
<Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]}
<、あなたが提供する、--><が12323<Message ID>=<がリソースで記載しない>=なにも旗を揚げさせる、>は等しいです。[UDP、<ドメイン名サーバポート>]
encoded as the 8 octet message
8八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 0 | 12323 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | 0 | 12323 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+
to host S and receives back from host S the reply
Sを接待して、ホストSから回答を受け取り返します。
<I-Provide> <Flags>=none <Message-ID>=12323
<Resource-List>={}
<はID>= 12323を通信させている<<リソースリスト>=を><旗の>=なにもにIで提供しません。{}
encoded as the 4 octet message
4八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+
| 4 | 0 | 12323 |
+-----+-----+-----+-----+
+-----+-----+-----+-----+ | 4 | 0 | 12323 | +-----+-----+-----+-----+
denying any support for UDP based domain name service.
UDPのどんなサポートも否定すると、ドメイン名サービスは基づきました。
In desperation host M again queries host R, this time excluding
host S from consideration, and sends the request
ホストMは、苦し紛れに、今回がホストSを考慮に入れないようにして、再びホストRについて質問して、要求を送ります。
<Does-Anyone-Provide?> <Flags>=none <Message-ID>=12324
<Resource-List>=
{[TCP, <DOMAIN-NAME-SERVER-PORT>] {S},
[UDP, <DOMAIN-NAME-SERVER-PORT>] {S}}
<、だれでも提供する、--><が12324<Message ID>=<がリソースで記載しない>=なにも旗を揚げさせる、>は等しいです。[TCP、<ドメイン名サーバポート>]S、[UDP、<ドメイン名サーバポート>]S
encoded as the 22 octet message
22八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+
| 3 | 0 | 12324 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 2 | 53 | 1 | S |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 17 | 2 | 53 | 1 | S |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+ | 3 | 0 | 12324 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 6 | 2 | 53 | 1 | S| +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 17 | 2 | 53 | 1 | S| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
Accetta [Page 14] RFC 887 December 1983 Resource Location Protocol
Accetta[14ページ]RFC887 1983年12月のリソース位置のプロトコル
and this time receives the reply
そして、今回は回答を受け取ります。
<They-Provide> <Flags>=none <Message-ID>=12324
<Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {T}}
<、それら、-ID>= 12324を通信させている<<リソースリスト>=を><旗の>=なにもに提供しないでください。[UDP、<ドメイン名サーバポート>]T
encoded as the 13 octet message
13八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+-----+-----+-----+-----+
| 5 | 0 | 12324 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | T |
+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | 5 | 0 | 12324 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | T| +-----+-----+-----+-----+-----+
from host R which of course host M again insists on confirming
by sending the request
ホストRから、どれがもちろん再びMを接待するかが要求を送ることによって確認すると主張します。
<Do-You-Provide?> <Flags>=none <Message-ID>=12325
<Resource-List>=
{[UDP, <DOMAIN-NAME-SERVER-PORT>]}
<、あなたが提供する、--><が12325<Message ID>=<がリソースで記載しない>=なにも旗を揚げさせる、>は等しいです。[UDP、<ドメイン名サーバポート>]
encoded as the 8 octet message
8八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 0 | 12325 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | 0 | 12325 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+
to host T and finally receives confirmation from host T with
the reply
最終的にTを接待するのは回答でホストTから確認を受け取ります。
<I-Provide> <Flags>=none <Message-ID>=12325
<Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]}
<はID>= 12325を通信させている<<リソースリスト>=を><旗の>=なにもにIで提供しません。[UDP、<ドメイン名サーバポート>]
encoded as the 8 octet message
8八重奏メッセージとして、コード化されます。
+-----+-----+-----+-----+-----+-----+-----+-----+
| 4 | 0 | 12325 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | 4 | 0 | 12325 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+
that it indeed provides domain name translation service at UDP
port 53.
本当に、それはUDPポート53でドメイン名翻訳サービスを提供します。
A. Assigned Numbers
A。 規定番号
The "well-known" UDP port number for the Resource Location Protocol is 39 (47 octal).
Resource Locationプロトコルのための「よく知られる」UDPポートナンバーは39(47 8進)です。
Accetta [Page 15] RFC 887 December 1983 Resource Location Protocol
Accetta[15ページ]RFC887 1983年12月のリソース位置のプロトコル
REFERENCES
参照
[1] Postel, J.
User Datagram Protocol.
RFC 768, USC/Information Sciences Institute, August, 1980.
[1] ポステル、J.ユーザー・データグラム・プロトコル。 RFC768、科学が1980年8月に設けるUSC/情報。
[2] Postel, J.
File Transfer Protocol.
RFC 765, USC/Information Sciences Institute, June, 1980.
[2] ポステル、J.ファイル転送プロトコル。 RFC765、科学が1980年6月に設けるUSC/情報。
[3] Postel, J.
Internet Protocol - DARPA Internet Program Protocol Specification.
RFC 791, USC/Information Sciences Institute, September, 1981.
[3] ポステル、J.インターネットは議定書を作ります--DARPAインターネットプログラムプロトコル仕様。 RFC791、科学が1981年9月に設けるUSC/情報。
[4] Postel, J.
Transmission Control Protocol- DARPA Internet Program Protocol
Specification.
RFC 793, USC/Information Sciences Institute, September, 1981.
[4] J.トランスミッション制御プロトコルポステル、DARPAインターネットプログラムプロトコル仕様。 RFC793、科学が1981年9月に設けるUSC/情報。
[5] Postel, J.
Internet Control Message Protocol - DARPA Internet Program
Protocol Specification.
RFC 792, USC/Information Sciences Institute, September, 1981.
[5] ポステル、J.インターネットはメッセージプロトコルを制御します--DARPAインターネットプログラムプロトコル仕様。 RFC792、科学が1981年9月に設けるUSC/情報。
[6] Reynolds, J., and J. Postel.
Assigned Numbers.
RFC 870, USC/Information Sciences Institute, October, 1983.
[6] レイノルズ、J.、およびJ.ポステル。 規定番号。 RFC870、科学が1983年10月に設けるUSC/情報。
[7] Gurwitz, R., and R. Hinden.
IP - Local Area Network Addressing Issues.
IEN 212, Bolt Beranek and Newman, September, 1982.
[7]Gurwitz、R.、およびR.Hinden。 IP--ローカル・エリア・ネットワーク問題提示。 IEN212とボルトBeranekとニューマン、1982年9月。
[8] Sollins, K.
The TFTP Protocol (revision 2).
RFC 783, MIT/Laboratory for Computer Science, June, 1981.
[8] Sollins、K. TFTPは(改正2)について議定書の中で述べます。 RFC783、MIT/コンピュータ科学研究所、1981年6月。
Accetta [Page 16]
Accetta[16ページ]
一覧
スポンサーリンク
