RFC1235 日本語訳
1235 Coherent File Distribution Protocol. J. Ioannidis, G. Maguire. June 1991. (Format: TXT=29345 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Ioannidis
Request for Comments: 1235 G. Maguire, Jr.
Columbia University
Department of Computer Science
June 1991
Ioannidisがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1235 G.マグワイア、Jr.コロンビア大学コンピュータサイエンス学部1991年6月
The Coherent File Distribution Protocol
コヒーレントファイル分配プロトコル
Status of this Memo
このMemoの状態
This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはCoherent File Distributionプロトコル(CFDP)について説明します。 これはインターネットコミュニティのためのExperimentalプロトコルです。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Introduction
序論
The Coherent File Distribution Protocol (CFDP) has been designed to speed up one-to-many file transfer operations that exhibit traffic coherence on media with broadcast capability. Examples of such coherent file transfers are identical diskless workstations booting simultaneously, software upgrades being distributed to more than one machines at a site, a certain "object" (bitmap, graph, plain text, etc.) that is being discussed in a real-time electronic conference or class being sent to all participants, and so on.
Coherent File Distributionプロトコル(CFDP)は、放送能力があるメディアのトラフィック一貫性を示す多くへの1つのファイル転送操作を早くするように設計されています。 そのような一貫性を持っているファイル転送に関する例は同時にサイト、すべての関係者に送られるリアルタイムの電子会議かクラスで議論している、ある「オブジェクト」(ビットマップ、グラフ、プレーンテキストなど)においてなどに1台以上のマシンに広げられるソフトウェアの更新をブートする同じディスクレスワークステーションです。
In all these cases, we have a limited number of servers, usually only one, and <n> clients (where <n> can be large) that are being sent the same file. If these files are sent via multiple one-to-one transfers, the load on both the server and the network is greatly increased, as the same data are sent <n> times.
これらのすべての場合には、私たちでは、同じファイルが送られる限られた数のサーバ、通常1だけ、および<n>クライアント(<n>が大きい場合があるところ)がいます。 複数の1〜1回の転送を通してこれらのファイルを送るなら、サーバとネットワークの両方の負荷を大いに増強します、n>回同じデータに<を送るとき。
We propose a file distribution protocol that takes advantage of the broadcast nature of the communications medium (e.g., fiber, ethernet, packet radio) to drastically reduce the time needed for file transfer and the impact on the file server and the network. While this protocol was developed to allow the simultaneous booting of diskless workstations over our experimental packet-radio network, it can be used in any situation where coherent transfers take place.
私たちはファイルサーバーとネットワークでファイル転送と影響に必要である時間を抜本的に短縮するのにコミュニケーション媒体(例えば、ファイバー、イーサネット、パケットラジオ)の放送本質を利用するファイル分配プロトコルを提案します。 このプロトコルが私たちの実験パケット無線ネットワークの上にディスクレスワークステーションの同時の穂ばらみを許容するために開発されていた間、どんな状況においてもコヒーレント転送が起こるところでそれを使用できます。
CFDP was originally designed as a back-end protocol; a front-end interface (to convert file names and requests for them to file handles) is still needed, but a number of existing protocols can be adapted to use with CFDP. Two such reference applications have been developed; one is for diskless booting of workstations, a simplified
CFDPは元々、バックエンドプロトコルとして設計されました。 フロントエンドインタフェース(ファイル名とハンドルをファイルするという要求を変換する)がまだ必要ですが、多くの既存のプロトコルをCFDPとの使用に適合させることができます。 そのような2つの参照アプリケーションを開発してあります。 1つはワークステーション、簡素化されたaのディスクレス穂ばらみのためのものです。
Ioannidis & Maguire, Jr. [Page 1] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[1ページ]RFC1235CFDP1991年6月
BOOTP [3] daemon (which we call sbootpd) and a simple, TFTP-like front end (which we call vtftp). In addition, our CFDP server has been extended to provide this front-end interface. We do not consider this front-end part of the CFDP protocol, however, we present it in this document to provide a complete example.
BOOTP[3]デーモン(私たちがsbootpdと呼ぶ)、および簡単で、TFTPのようなフロントエンド(私たちがvtftpと呼ぶ)。 さらに、このフロントエンドインタフェースを提供するために私たちのCFDPサーバを広げてあります。 私たちは、このフロントエンドがCFDPプロトコルの一部であると考えないで、しかしながら、完全な例を提供するために本書ではそれを提示します。
The two clients and the CFDP server are available as reference
implementations for anonymous ftp from the site CS.COLUMBIA.EDU
(128.59.16.20) in directory pub/cfdp/. Also, a companion document
("BOOTP extensions to support CFDP") lists the "vendor extensions"
for BOOTP (a-la RFC-1084 [4]) that apply here.
128.59に、.16はBOOTPのために「ベンダー拡大」を記載しますディレクトリpub/cfdp/仲間でも.20が、)ドキュメントである(「CFDPをサポートするBOOTP拡張子」)。2人のクライアントとCFDPサーバがサイトCS.COLUMBIA.EDUからのアノニマスFTPのための参照実装として手があいている、((ここに適用するRFC-1084[4])のように。
Overview
概要
CFDP is implemented as a protocol on top of UDP [5], but it can be implemented on top of any protocol that supports broadcast datagrams. Moreover, when IP multicast [6] implementations become more widespread, it would make more sense to use a multicast address to distribute CFDP packets, in order to reduce the overhead of non- participating machines.
CFDPはプロトコルとしてUDP[5]の上で実装されますが、ブロードキャスト・データグラムを支えるどんなプロトコルの上でもそれを実装することができます。そのうえ、IPマルチキャスト[6]実装が、より広範囲になると、CFDPパケットを分配するのにマルチキャストアドレスを使用するより多くの意味になるでしょう、非参加しているマシンのオーバーヘッドを下げるために。
A CFDP client that wants to receive a file first contacts a server to
acquire a "ticket" for the file in question. This server could be a
suitably modified BOOTP server, the equivalent of the tftpd daemon,
etc. The server responds with a 32-bit ticket that will be used in
the actual file transfers, the block size sent with each packet
(which we shall call "BLKSZ" from now on), and the size (in bytes) of
the file being transferred ("FILSZ"). BLKSZ should be a power of
two. A good value for BLKSZ is 512. This way the total packet size
(IPheader+UDPheader+CFDPheader+data=20+8+12+512=552), is kept well
under the magic number 576, the minimum MTU for IP networks [7].
Note that this choice of BLKSZ supports transfers of files that are
up to 32 Mbytes in size. At this point, the client should allocate
enough buffer space (in memory, or on disk) so that received packets
can be placed directly where they belong, in a way similar to the
NetBLT protocol [8].
ファイルを受け取りたがっているCFDPクライアントは、最初に、問題のファイルの「チケット」を取得するためにサーバに連絡します。 このサーバは適当に変更されたBOOTPサーバ、tftpdデーモンの同等物であるかもしれませんなど。 実際のファイル転送に使用される、32ビットのチケット、各パケットと共に送られたブロック・サイズ(私たちがこれから先"BLKSZ"と呼ぶつもりである)、および移されるファイルのサイズ(バイトによる)("FILSZ")でサーバは反応します。 BLKSZは2のパワーであるべきです。 BLKSZのための値打ち品は512です。 総パケットサイズ(IPheader+UDPheader+CFDPheader+データ=20+8+12+512=552)がマジックナンバー576の下の保たれた井戸であるこの方法、IPのための最小のMTUは[7]をネットワークでつなぎます。 BLKSZのこの選択がサイズで最大32Mbytesであるファイルの転送をサポートすることに注意してください。 ここに、クライアントは直接それらが属するところに容認されたパケットを置くことができるように、十分なバッファ領域(メモリか、ディスクの上の)を割り当てるべきです、NetBLTプロトコル[8]と同様の方法で。
It is assumed that the CFDP server will also be informed about the ticket so that it can respond to requests. This can be done, for example, by having the CFDP server and the ticket server keep the table of ticket-to-filename mappings in shared memory, or having the CFDP server listening on a socket for this information. To reduce overhead, it is recommended that the CFDP server be the same process as the front-end (ticket) server.
また、CFDPサーバが要求に応じることができるようにチケットに関して知識があるようになると思われます。 例えば、CFDPサーバとチケットサーバに共有メモリにチケットからファイル名へのマッピングのテーブルを保たせるか、またはこの情報のためにソケットの上に聴かれるCFDPサーバを持っていることによって、これができます。 経費を削減するために、CFDPサーバがフロントエンド(チケット)サーバと同じプロセスであることはお勧めです。
After the client has received the ticket for the file, it starts listening for (broadcast) packets with the same ticket, that may exist due to an in-progress transfer of the same file. If it cannot
クライアントがファイルのチケットを受け取った後に、同じチケットで(放送)パケットの聞こうとし始めて、それは同じファイルの進行中の転送に当然の状態で存在するかもしれません。 それがそうすることができないなら
Ioannidis & Maguire, Jr. [Page 2] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[2ページ]RFC1235CFDP1991年6月
detect any traffic, it sends to the CFDP server a request to start transmitting the whole file. The server then sends the entire file in small, equal-sized packets consisting of the ticket, the packet sequence number, the actual length of data in this packet (equal to BLKSZ, except for the last packet in the transfer), a 32-bit checksum, and the BLKSZ bytes of data. Upon receipt of each packet, the client checksums it, marks the corresponding block as received and places its contents in the appropriate place in the local file. If the client does not receive any packets within a timeout period, it sends to the CFDP server a request indicating which packets it has not yet received, and then goes back to the receiving mode. This process is repeated until the client has received all blocks of the file.
あらゆるトラフィックを検出してください、そして、それは全体のファイルを送り始めるという要求をCFDPサーバに送ります。 そして、サーバで、小さくて、等しいサイズのパケットのファイル全体はチケット、パケット一連番号、このパケット(転送における最後のパケット以外のBLKSZと等しい)の実際の長さに関するデータ、32ビットのチェックサム、およびデータのBLKSZバイトから成ります。 各パケット、クライアントチェックサムを受け取り次第それ、受け取るように対応するブロックを示して、ローカルファイルに適切な場所にコンテンツを置きます。 クライアントがタイムアウト時間以内にどんなパケットも受けないなら、それは、要求にそれがまだどのパケットを受けていないかをCFDPサーバに示させて、受信モードに戻ります。 クライアントがファイルのすべてのブロックを受け取るまで、このプロセスは繰り返されます。
The CFDP server accepts requests for an entire file ("full" file
requests, "FULREQ"s), or requests for a set of BLKSZ blocks
("partial" file requests, "PARREQ"s). In the first case, the server
subsequently broadcasts the entire file, whereas in the second it
only broadcasts the blocks requested. If a FULREQ or a PARREQ
arrives while a transfer (of the same file) is in progress, the
requests are ignored. When the server has sent all the requested
packets, it returns to its idle state.
CFDPサーバはファイル全体に関する要求を受け入れます。aを求める要求はBLKSZブロックをセットしました。(「完全な」ファイルが要求する、「FULREQ、「s、)、(「部分的な」ファイルが要求する、「PARREQ「s)。」 前者の場合、サーバは次に、ファイル全体を放送しますが、2番目では、それは要求されたブロックを放送するだけです。 転送(同じファイルの)が進行していますが、FULREQかPARREQが到着するなら、要求は無視されます。 サーバがすべての要求されたパケットを送ったとき、それは活動していない状態に戻ります。
The CFDP server listens for requests on UDP/IP port "cfdpsrv". The
clients accept packets on UDP/IP port "cfdpcln" (both to be defined
by the site administrator), and this is the destination of the
server's broadcasts. Those two port numbers are sent to the client
with the initial handshake packet, along with the ticket. If the
minimal ticket server is implemented as described later in this
document, it is recommended (for interoperability reasons) that it
listens for requests on UDP/IP port 120 ("cfdptkt").
CFDPサーバはIPポートUDP/"cfdpsrv"に関する要求の聞こうとします。 クライアントはIPポートUDP/"cfdpcln"(ともにサイトの管理者によって定義される)でパケットを受け入れます、そして、これはサーバの放送の目的地です。 チケットに伴う初期の握手パケットと共にそれらの2つのポートナンバーをクライアントに送ります。 最小量のチケットサーバが本書では後述のように実装されるなら、UDP/IPポート120("cfdptkt")に関する要求の聞こうとすることが勧められます(相互運用性理由で)。
Let us now examine the protocol in more detail.
現在、さらに詳細にプロトコルを調べましょう。
Protocol Specification
プロトコル仕様
Initial Handshake (not strictly part of the protocol):
Handshakeに頭文字をつけてください(厳密に、プロトコルを離れさせません):
The client must acquire a ticket for the file it wishes to transfer, and the CFDP server should be informed of the ticket/filename mapping. Again, this can be done inside a BOOTP server, a modified TFTP server, etc., or it can be part of the CFDP server itself. We present here a suggested protocol for this phase.
クライアントはそれが移したがっているファイルのチケットを入手しなければなりません、そして、CFDPサーバはチケット/ファイル名マッピングにおいて知識があるべきです。 一方、BOOTPサーバ、変更されたTFTPサーバなどでこれができるか、それはCFDPサーバ自体の一部であるかもしれません。 私たちはこのフェーズのためにここに提案されたプロトコルを提示します。
The client sends a "Request Ticket" (REQTKT) request to the CFDP Ticket server, using UDP port "cfdptkt". If the address of the server is unknown, the packet can be sent to the local broadcast address. Figure 1 shows the format of this packet.
UDPポート"cfdptkt"を使用して、クライアントは(REQTKT)がCFDP Ticketサーバに要求する「要求チケット」を送ります。 サーバのアドレスが未知であるなら、ローカル放送アドレスにパケットを送ることができます。 図1はこのパケットの書式を示しています。
Ioannidis & Maguire, Jr. [Page 3] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[3ページ]RFC1235CFDP1991年6月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'R' | 'Q' | 'T' | 'K' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
\ Filename, null-terminated, up to 512 octets \
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'R'| 'Q'| '、'| 'K'| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //\ファイル名、最大512ヌルで終えられた八重奏\//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 1: "ReQuest TicKet" packet.
図1: "ReQuest TicKet"パケット。
The filename is limited to 512 octets. This should not cause a problem in most, if not all, cases.
ファイル名は512の八重奏に制限されます。 これは大部分の問題(すべてでなくても)にケースを引き起こすべきではありません。
The ticket server replies with a "This is Your Ticket" (TIYT) packet containing the ticket. Figure 2 shows the format of this packet.
「これはYour Ticket(TIYT)である」パケットがチケットを含んでいて、チケットサーバが返答します。 図2はこのパケットの書式を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'T' | 'I' | 'Y' | 'T' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLKSZ (by default 512) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILSZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address of CFDP server (network order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | '、'| '私'| 'Y'| '、'| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「チケット」| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLKSZ、(デフォルトで、512)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FILSZ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CFDPサーバ(ネットワークオーダー)のIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントUDPは#cfdpcln()を移植します。| サーバUDPポート#(cfdpsrv)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 2: "This Is Your Ticket" packet.
図2: 「このIs Your Ticket」パケット。
The reply is sent to the UDP port that the RQTK request came from. The IP address of the CFDP server is provided because the original handshake server is not necessarily on the same machine as the ticket server, let alone the same process. Similarly, the cfdpcln and cfdpsrv port numbers (in network order) are communicated to the client. If the client does not use this ticket server, but rather uses BOOTP or something else, that other server should be responsible for providing the values of cfdpcln and cfdpsrv. The ticket server also communicates this ticket/filename/filesize to the real CFDP server. It is recommended that the ticket requests be handled by the
RQTK要求が来たUDPポートに回答を送ります。 まして、必ずチケットサーバと同じマシン、同じプロセスの上にオリジナルの握手サーバがあるというわけではないので、CFDPサーバのIPアドレスを提供します。 同様に、cfdpclnとcfdpsrvポートナンバー(ネットワークオーダーにおける)はクライアントに伝えられます。 クライアントがこのチケットサーバを使用しませんが、むしろBOOTPか他の何かを使用するなら、その他のサーバはcfdpclnとcfdpsrvの値を提供するのに原因となるべきです。 また、チケットサーバは/が実際のCFDPサーバにfilesizeするこのチケット/ファイル名を伝えます。チケット要求が扱われるのは、お勧めです。
Ioannidis & Maguire, Jr. [Page 4] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[4ページ]RFC1235CFDP1991年6月
regular CFDP server, in which case informing the CFDP server of the ticket/filename binding is trivial (as it is internal to the process).
通常のCFDPサーバ、その場合、チケット/ファイル名結合のCFDPサーバを知らせるのは些細です(それがプロセスに内部であるときに)。
Once the client has received the ticket for the filename it has requested, the file distribution can proceed.
クライアントがいったんそれが要求したファイル名のチケットを受け取ると、ファイル分配は続くことができます。
Client Protocol:
クライアントプロトコル:
Once the ticket has been established, the client starts listening for broadcast packets on the cfdpcln/udp port that have the same "ticket" as the one it is interested in. In the state diagram below, the client is in the CLSTART state. If the client can detect no packets with that ticket within a specified timeout period, "TOUT-1", it assumes that no transfer is in progress. It then sends a FULREQ packet (see discussion above) to the CFDP server, asking it to start transmitting the file, and goes back to the CLSTART state (so that it can time out again if the FULREQ packet is lost). Figure 3 shows the format of the FULREQ packet.
チケットがいったん設立されると、クライアントはcfdpcln/udpポートの上のそれが興味を持っているものと同じ「チケット」を持っている放送パケットの聞こうとし始めます。 以下の州のダイヤグラムには、クライアントがCLSTART状態にあります。 クライアントが指定されたタイムアウト時間以内にそのチケットでパケットを全く検出できないなら、「-何1インチも売り込んで、転送が全く進行していないと仮定します」。 それが次に、ファイルを送り始めるようにそれに頼んで、FULREQパケット(議論が上であることを見る)をCFDPサーバに送って、CLSTART状態に戻る、(それがそうすることができるそう、タイムアウト、一方、FULREQパケットが無くなるかどうか、) 図3はFULREQパケットの書式を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'F' | 0 | length == 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「チケット」| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'F'| 0 | 長さ=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 3: FULREQ (FULl file REQuest) packet.
図3: FULREQ(FULlファイルREQuest)パケット。
When the first packet arrives, the client moves to the RXING state and starts processing packets. Figure 4 shows the format of a data packet.
最初のパケットが到着するとき、クライアントは、RXING状態に移行して、パケットを処理し始めます。 図4はデータ・パケットの書式を示しています。
Ioannidis & Maguire, Jr. [Page 5] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[5ページ]RFC1235CFDP1991年6月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block number | data length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
\ up to BLKSZ octets of data \
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「チケット」| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 街区番号| データの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | データ\//のBLKSZ八重奏までの//\| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 4: Data Packet
図4: データ・パケット
The format is self-explanatory. "Block number" the offset (in multiples of BLKSZ) from the beginning of the file, data length is always BLKSZ except for the very last packet, where it can be less than that, and the rest is data.
形式は自明です。 「数を妨げてください。」ファイルの始まりからのオフセット(BLKSZの倍数における)、いつもデータの長さは最後のまさしくそのパケット以外のBLKSZです。(そこでは、それがそれより少ない場合があり、残りはデータです)。
As each packet arrives, the client verifies the checksum and places the data in the appropriate position in the file. While the file is incomplete and packets keep arriving, the client stays in the RXING state, processing them. If the client does not receive any packets within a specified period of time, "TOUT-2", it times out and moves to the INCMPLT state. There, it determines which packets have not yet been received and transmits a PARREQ request to the server. This request consists of as many block numbers as will fit in the data area of a data packet. If one such request is not enough to request all missing packets, more will be requested when the server has finished sending this batch and the client times out. Also, if the client has sent a PARREQ and has not received any data packets within a timeout period, "TOUT-3", it retransmits the same PARREQ. Figure 5 shows the format of the PARtial REQuest packet.
各パケットが到着するのに従って、クライアントは、ファイルの適切な見解にチェックサムについて確かめて、データを置きます。 ファイルが不完全であり、パケットが到着し続ける間、それらを処理して、クライアントはRXING状態にいます。 クライアントが指定された期間以内にどんなパケットも受けないなら「-何2インチも売り込んでください、それ、INCMPLT状態への回とムーヴス、」 そこでは、それは、どのパケットがまだ受け取られていないかを決定して、PARREQ要求をサーバに伝えます。この要求はデータ・パケットのデータ領域をうまくはめ込むのと同じくらい多くの街区番号から成ります。 サーバが、このバッチとクライアント回を出し終えたとき、そのような要求の1つがすべてのなくなったパケットを要求するために十分でないなら、以上は要求されるでしょう。 クライアントがPARREQを送って、タイムアウト時間以内にまだデータ・パケットを受けていないなら、また「-何3インチも売り込んで、同じPARREQをまた再送します」。 図5はPARtial REQuestパケットの書式を示しています。
Ioannidis & Maguire, Jr. [Page 6] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[6ページ]RFC1235CFDP1991年6月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'P' | 0 | data length (2*N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block #0 | Block #1 |
| Block #2 | Block #3 |
/ /
\ data (block numbers requested) \
/ /
| Block #N-2 | Block #N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「チケット」| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'P'| 0 | データの長さ(2*N)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ブロック#0| ブロック#1| | ブロック#2| ブロック#3| //\データ(数が要求したブロック)\//| ブロック#N-2| ブロック#N-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 5: PARREQ (PARtial file REQuest) packet.
図5: PARREQ(PARtialファイルREQuest)パケット。
When all packets have been received the client enters the CLEND state and stops listening.
すべてのパケットを受け取ったとき、クライアントは、CLEND状態に入って、聴くのを止めます。
Figure 6 summarizes the client's operations in a state diagram.
図6は州のダイヤグラムでクライアントの操作をまとめます。
Ioannidis & Maguire, Jr. [Page 7] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[7ページ]RFC1235CFDP1991年6月
+-----------+
| CLSTART |
| | <---.
| send | | timeout TOUT-1
| FULREQ | ----'
| |
+-----------+
|
received packet | received packet
.-----------------------. |
| V V
+---------+ +---------+
| INCMPLT | | RXING |
| | timeout | | <---.
| send |<------------| process | | received packet
| PARREQ | TOUT-2 | packet | ----'
| | | |
+---------+ +---------+
^ | |
| | |finished
`---' |
timeout V
TOUT-3 +---------+
| CLEND |
+---------+
+-----------+ | CLSTART| | | <--. | 発信してください。| | タイムアウトTOUT-1| FULREQ| ----' | | +-----------+ | 容認されたパケット| 容認されたパケット。-----------------------. | | +に対するV---------+ +---------+ | INCMPLT| | RXING| | | タイムアウト| | <--. | 発信してください。| <、-、-、-、-、-、-、-、-、-、-、--、| プロセス| | 容認されたパケット| PARREQ| 勧誘者-2| パケット| ----' | | | | +---------+ +---------+ ^ | | | | |'終わっている‘---' | タイムアウトV TOUT-3+---------+ | CLEND| +---------+
Fig. 6: Client State Transition Diagram
図6: 属国変遷ダイヤグラム
Server Protocol:
サーバプロトコル:
As described above, the CFDP server accepts two kinds of requests: a request for a full file transfer, "FULREQ", and a request for a partial (some blocks only) file transfer, "PARREQ". For the first, it is instructed to start sending out the contents of a file. For the second, it will only send out the requested blocks. The server should know at all times which files correspond to which "tickets", and handle them appropriately. Note that this may run into implementation limits on some Unix systems (e.g., on older systems, a process could only have 20 files open at any one time), but that should not normally pose a problem.
上で説明されるように、CFDPサーバは2種類の要求を受け入れます: 部分的な(いくつかのブロック専用)ファイル転送、"PARREQ"を求める完全なファイル転送を求める要求、"FULREQ"、および要求。 1番目に関しては、ファイルのコンテンツを出し始めるよう命令されます。 2番目のために、それは要求されたブロックを出すだけでしょう。 サーバは、適切にいつもどのファイルがどの「チケット」に対応するかを知って、それらを扱うべきです。 これがいくつかのUnixシステムにおける実装限界を出くわすかもしれませんが(例えば、より古いシステムの上では、プロセスはいかなる時も開いている20個のファイルしか持っていないかもしれません)、通常、それが問題を設定するはずがないことに注意してください。
The server is initially in the SIDLE state, idling (see diagram below). When it receives a FULREQ packet, it goes to the FULSND state, whence it broadcasts the entire contents of the file whose ticket was specified in the FULREQ packet. When it is done, it goes back to the SIDLE state. When it receives a PARREQ packet, it goes to the PARSND state and broadcasts the blocks specified in the PARREQ packet. When it has finished processing the block request, it goes
アイドリング、サーバが初めはSIDLE状態にあります(以下のダイヤグラムを見てください)。 FULREQパケットを受けるとき、FULSND状態に行きます、起源のときに。それはチケットがFULREQパケットで指定されたファイルの全体のコンテンツを放送します。 完了していると、それはSIDLE状態に戻ります。 PARREQパケットを受けるとき、それは、PARSND状態に行って、PARREQパケットで指定されたブロックを放送します。 ブロック要求を処理し終えたとき、それは行きます。
Ioannidis & Maguire, Jr. [Page 8] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[8ページ]RFC1235CFDP1991年6月
once again back to the SIDLE state.
もう一度SIDLE状態に。
receive +-------+ receive
.---------------| SIDLE |---------------.
| FULREQ +-------+ PARREQ |
| ^ ^ |
| | | |
V | | V
+--------+ | | +--------+
| FULSND | | | | PARSND |
| | done | | done | |
| send |------------' `------------| send |
| entire | | req'ed |
| file | | blocks |
+--------+ +--------+
+を受けてください。-------+は受信します。---------------| にじり寄ってください。|---------------. | FULREQ+-------+ PARREQ| | ^ ^ | | | | | V| | +に対して--------+ | | +--------+ | FULSND| | | | PARSND| | | します。| | します。| | | 発信してください。|------------' `------------| 発信してください。| | 全体| | req'ed| | ファイル| | ブロック| +--------+ +--------+
Fig. 7: Server State Transition Diagram
図7: サーバ状態遷移ダイヤグラム
Packet Formats
パケット・フォーマット
The structure of the packets has been already described. In all
packet formats, numbers are assumed to be in network order ("big-
endian"), including the ticket and the checksum.
パケットの構造は既に説明されます。 すべてのパケット・フォーマットでは、チケットとチェックサムを含んでいて、数がネットワークオーダー(「大きいエンディアン」)にあると思われます。
The checksum is the two's complement of the unsigned 32-bit sum with no end-around-carry (to facilitate implementation) of the rest of the packet. Thus, to compute the checksum, the sender sets that field to zero and adds the contents of the packet including the header. The it takes the two's complement of that sum and uses it as the checksum. Similarly, the receiver just adds the entire contents of the packet, ignoring overflows, and the result should be zero.
チェックサムはおよそ終わりがパケットの残りで運ぶことのない(実装を容易にする)未署名の32ビットの合計の2の補数です。 したがって、送付者は、チェックサムを計算するために、その分野をゼロに設定して、ヘッダーを含むパケットのコンテンツを加えます。 それは、その合計の2の補数を取って、チェックサムとしてそれを使用します。 オーバーフローを無視して、同様に、受信機はただパケットの全体のコンテンツを加えます、そして、結果はゼロであるべきです。
Tuneable Parameters: Packet Size, Delays and Timeouts
同調可能パラメタ: パケットサイズ、遅れ、およびタイムアウト
It is recommended that the packet size be less than the minimum MTU on the connected network where the file transfers are taking place. We want this so that there be no fragmentation; one UDP packet should correspond to one hardware packet. It is further recommended that the packet size be a power of two, so that offsets into the file can be computed from the block number by a simple logical shift operation. Also, it is usually the case that page-aligned transfers are faster on machines with a paged address space. Small packet sizes are inefficient, since the header will be a larger fraction of the packet, and packets larger than the MTU will be fragmented. A good selection for BLKSZ is 512 or 1024. Using that BLKSZ, one can transfer files up to 32MB or 64MB respectively (since the limit is the 16-bit packet sequence number). This is adequate for all but copying complete disks, and it allows twice as many packets to be
パケットサイズがファイル転送が行われている接続ネットワークの最小のMTUより少ないのは、お勧めです。 私たちが、このそうが欲しいと思う、それ、そこに、いてください、断片化がありません。 あるUDPパケットが1つのハードウェアパケットに対応するはずです。 パケットサイズが2のパワーであることはさらにお勧めです、街区番号から簡単な論理桁送り操作でファイルの中へのオフセットを計算できるように。 また、通常、マシンでは、ページで並べられた転送が呼び出されたアドレス空間で、より速いのは、事実です。 小型小包サイズは効率が悪いです、ヘッダーがパケット、およびMTUが断片化されるより大きいパケットのさらに大きい部分になるので。 BLKSZに、良い選択は、512か1024です。 BLKSZ、ものが移すことができる使用はそれぞれ最大32MBか64MBをファイルします(限界が16ビットのパケット一連番号であるので)。 これは完全なディスクをほとんどコピーするのにおいて適切であり、それは、二度同じくらい多くのパケットは許容します。
Ioannidis & Maguire, Jr. [Page 9] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[9ページ]RFC1235CFDP1991年6月
requested in a PARREQ request than if the sequence number were 32 bits. If larger files must be transferred, they could be treated as multiple logical files, each with a size of 32MB (or 64MB).
PARREQ要求で要求されている、一連番号が32ビットであるなら。 より大きいファイルを移さなければならないなら、複数の論理的なファイルとしてそれらを扱うかもしれません、それぞれ32MB(または、64MB)のサイズで。
Since most UDP/IP implementations do not buffer enough UDP datagrams, the server should not transmit packets faster than its clients can consume them. Since this is a one-to-many transfer, it is not desirable to use flow-control to ensure that the server does not overrun the clients. Rather, we insert a small delay between packets transmitted. A good estimate of the proper delay between two successive packets is twice the amount of time it takes for the interface to transmit a packet. On Unix implementations, the ping program can be used to provide an estimate of this, by specifying the same packet length on the command line as the expected CFDP packet length (usually 524 bytes).
ほとんどのUDP/IP実装が十分なUDPデータグラムをバッファリングしないので、サーバはクライアントが彼らを消費できるより速くパケットを伝えるべきではありません。 これが多くへの1回の転送であるので、サーバがクライアントをオーバランさせないのを保証するのにフロー制御を使用するのは望ましくはありません。 むしろ、私たちは伝えられたパケットの間に小さい遅れを挿入します。 2つの連続したパケットの間の適切な遅れの良い見積りはインタフェースがパケットを伝えるにはかかる時間の2倍です。 Unix実装では、この見積りを提供するのにピングプログラムを使用できます、予想されたCFDPパケット長(通常524バイト)としてコマンドラインで同じパケット長を指定することによって。
The timeouts for the client are harder to compute. While there is a provision for the three timeouts (TOUT-1, TOUT-2 and TOUT-3) to be different, there is no compelling reason not to make them the same. Experimentally, we have determined that a timeout of 6-8 times the transfer time for a packet works best. A timeout of less than that runs the risk of mistaking a transient network problem for a timeout, and more than that delays the transfer too much.
クライアントのためのタイムアウトはより計算しにくいです。 3回のタイムアウト(TOUT-1、TOUT-2、およびTOUT-3)が異なっているように、支給がありますが、それらを同じにしないやむにやまれない理由は全くありません。 実験的に、私たちはパケットのための転送時間がうまくいくという6-8回の時代のそのaタイムアウトを決定しました。 それ以下のタイムアウトは一時的なネットワーク問題をタイムアウトに間違える危険を冒します、そして、それ以上は転送を遅らせ過ぎます。
Summary
概要
To summarize, here is the timeline of a sample file distribution using CFDP to three clients. Here we request a file with eight blocks. States are capitalized, requests are preceded with a '<' sign, replies are followed by a '>' sign, block numbers are preceded with a '#' sign, and actions are in parentheses:
まとめるためにある、ここに、サンプルファイル分配に関するスケジュールが、CFDPを3人のクライアントまで使用することであります。 ここで、私たちは8ブロックがあるファイルを要求します。 州は大文字で書かれます、そして、要求は'<'サインで先行されています、そして、'>'サインは回答を支えています、そして、街区番号は'#'サインで先行されています、そして、動作が括弧にあります:
SERVER CLIENT1 CLIENT-2 CLIENT-3 comments
SERVER CLIENT1 CLIENT-2 CLIENT-3コメント
IDLE everybody idle
CLSTART CL1 wants a file
<TKRQ requests ticket
TIYT> server replies
(timeout) listens for traffic
<FULREQ full request
#0 RXING CL1 starts receiving
(rx 0)
#1 (rx 1) CLSTART CL2 decides to join
<TKRQ
#2 (rx 2) SRV still sending
TIYT> responds to TKRQ
#3 (rx 3) (listens) CL2 listens
RXING found traffic
#0RXING CL1が受け始める(rx0)使用されていないCLSTART CL1が欲しいファイル<TKRQ要求チケットTIYT>サーバ回答(タイムアウト)が交通<FULREQまでいっぱいに聴くみんなが#1(rx1)CLSTART CL2を要求するIDLEは、<TKRQ#2(rx2)SRVを接合すると決めます、それでも、>がTKRQ#3(rx3)(聴く)CL2に反応させる送付TIYTは交通が見つけられたRXINGを聴きます。
Ioannidis & Maguire, Jr. [Page 10] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[10ページ]RFC1235CFDP1991年6月
#4 (rx 4) (rx 4) CLSTART CL3 joins in
<TKRQ
#5 (missed) (rx 5) CL1 missed a packet
TIYT> (listens)
#6 (rx 6) (rx 6) RXING CL3 found traffic
#4 (rx4) (rx4) CLSTART CL3は<TKRQ#5(取り逃がす)(rx5)のCL1の逃されたaパケットTIYT>(聴く)#6(rx6)(rx6)RXING CL3の備え付けることの交通に参加します。
#7 (rx 7) (rx 7) (rx 7) Server finished
IDLE
(wait) (wait) (wait) CL1 managed to
(timeout) (wait) (wait) timeout
<PARREQ[5] (timeout) (timeout) CL1 blockrequests...
#5 (rx 5) <PARREQ[0123] <PARREQ[0123456] ignored by SRV
CLEND CL1 has all packets
IDLE (wait) (wait) CL2+3 missed #5
(timeout) (timeout)
<PARREQ[0123] <PARREQ[0123456] CL2's req gets
#0 (rx 0) (rx 0) through, CL3 ignored
#1 (rx 1) (rx 1) moving along
#2 (rx 2) (rx 2)
#3 (rx 3) (rx 3)
IDLE CLEND (wait) CL2 finished
(timeout)
<PARREQ[456]
#4 (rx 4)
#5 (rx 5)
#5 (rx 6)
IDLE CLEND CL3 finished
#7 (rx7) (rx7) (rx7) サーバの終わっているIDLE(待ち)(待ち)(待っています)CL1は(タイムアウト)(待っています)(待っている)タイムアウト<PARREQ[5](タイムアウト)(タイムアウト)CL1 blockrequestsに管理しました… #5 (rx5) 無視..持つ..パケット..待つ..待つ..逃す..タイムアウト..タイムアウト..得る..突き抜ける..無視..動く..待つ..終わる..タイムアウト..終える
References
参照
[1] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, MIT, June
1981.
[1]Sollins、K.、「TFTPプロトコル(改正2)」、RFC783、MIT、1981年6月。
[2] Finlayson, R., "Bootstrap Loading Using TFTP", RFC 906, Stanford,
June 1984.
[2] フィンリースン、R.、「TFTPを使用して、ローディングを独力で進んでください」、RFC906、スタンフォード、1984年6月。
[3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
Stanford and SUN Microsystems, September 1985.
[3] 耕地、W.とJ.ギルモアと「プロトコルを独力で進んでください」とRFC951とスタンフォードと太陽マイクロシステムズ、1985年9月。
[4] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1084,
USC/Information Sciences Institute, December 1988.
[4] レイノルズ、J.、「BOOTP売り主情報拡張子」、USC/情報科学が1988年12月に設けるRFC1084。
[5] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, August 1980.
[5] ポステル、J.、「ユーザー・データグラム・プロトコル」、RFC768、科学が1980年8月に設けるUSC/情報。
[6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[6] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、RFC1112、スタンフォード大学、1989年8月。
Ioannidis & Maguire, Jr. [Page 11] RFC 1235 CFDP June 1991
Ioannidisとマグワイア、Jr.[11ページ]RFC1235CFDP1991年6月
[7] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
Specification", RFC 791, DARPA, September 1981.
[7] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、DARPA、1981年9月。
[8] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data
Transfer Protocol", RFC 998, MIT, March 1987.
[8] クラーク、D.、ランバート、M.、およびL.チャン、「NETBLT:」 「バルク・データ転送プロトコル」、RFC998、MIT、1987年3月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
John Ioannidis Columbia University Department of Computer Science 450 Computer Science New York, NY 10027
ニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク 10027人のジョンIoannidisコロンビア大学部
EMail: ji@cs.columbia.edu
メール: ji@cs.columbia.edu
Gerald Q. Maguire, Jr. Columbia University Department of Computer Science 450 Computer Science New York, NY 10027
ジェラード・Q.マグワイア、ニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク 10027人のJr.コロンビア大学部
Phone: (212) 854-2736
以下に電話をしてください。 (212) 854-2736
EMail: maguire@cs.columbia.edu
メール: maguire@cs.columbia.edu
Ioannidis & Maguire, Jr. [Page 12]
Ioannidisとマグワイア、Jr.[12ページ]
一覧
スポンサーリンク
