RFC478 日本語訳

0478 FTP server-server interaction - II. R.D. Bressler, R. Thomas. March 1973. (Format: TXT=4199 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        B. Bressler
Request for Comments: 478                                      B. Thomas
NIC: 14947                                                           BBN
                                                           26 March 1973

Bresslerがコメントのために要求するワーキンググループB.をネットワークでつないでください: 478 B.トーマスNIC: 14947 BBN1973年3月26日

                    FTP Server-Server Interaction-II

FTPサーバサーバ相互作用II

   At the recent FTP meeting at BBN in Cambridge, one of the topics
   discussed was that of server-server interaction.  In a typical
   situation a user (A) conversing with two servers (B,C) is interested
   in retrieving a file from one site (B) and sending it to the other
   (C).

ケンブリッジのBBNの最近のFTPミーティングでは、議論した話題の1つはサーバサーバ相互作用のものでした。 典型的な状況では、2つのサーバ(B、C)と話すユーザ(A)は、1つのサイト(B)からファイルを取って、もう片方の(C)にそれを送りたがっています。

                          +------+
                          | USER |
                          |   A  |
                         /+------+\
                   control        control
                      /              \
                +------+            +------+
                |SERVER|    DATA    |SERVER|
                |   B  |----------->|  C   |
                +------+            +------+

+------+ | ユーザ| | A| /+------+ \コントロールコントロール/\+------+ +------+ |サーバ| データ|サーバ| | B|、-、-、-、-、-、-、-、-、-、--、>| C| +------+ +------+

   The consensus of the meeting was that mechanisms were necessary to
   make B and C aware of each other and to allow a data connection to be
   established without forcing each other to queue RFCs for local
   sockets before they exist.

ミーティングのコンセンサスはメカニズムがBとCを互いを意識するようにして、存在する前に互いに地方のソケットのためにRFCsを列に並ばせさせないでデータ接続が確立されるのを許容するのに必要であったということでした。

   The proposed solution to this problem was a command called PASSIVE
   (PASV?).  The following is our conclusion as to the meaning of the
   command and how it would be used.

この問題への提案された解決はPASSIVE(PASV?)と呼ばれるコマンドでした。 ↓これはコマンドとそれがどう使用されるだろうかに関する意味に関する私たちの結論です。

   Third party connections would be established using the SOCK command,
   which says "Be prepared to use socket S at Host H to establish your
   data connection", and the PASV command which says "open your data
   socket for listening, and upon receipt of a transfer command wait for
   an RFC rather than initiating one."

第三者接続は、「データ接続を証明するのにHost HでソケットSを使用するように用意してください」と言うSOCKコマンドと「聴取、RFCのための転送命令待ちおよびを受け取り次第1を開始するよりむしろデータソケットを開けてください」と言うPASVコマンドを使用することで確立されるでしょう。

   A positive acknowledgement to the PASV command indicates that the
   data socket has been opened for listening.  When an RFC for its data
   socket arrives after it has positively acknowledged a PASV command,
   the server should respond with a matching RFC to open the data
   connection (assuming, of course, that the incoming RFC is consistent
   with the previous SOCK commands, if any).

PASVコマンドへの積極的な承認は、データソケットが聴取のために開けられたのを示します。 明確にPASVコマンドを承諾した後にデータソケットのためのRFCが到着するとき、サーバは、データ接続(もちろん入って来るRFCが前のSOCKコマンドと一致していると仮定しますもしあれば)を開くために合っているRFCと共に反応するべきです。

Bressler                                                        [Page 1]

RFC 478             FTP Server-Server Interaction-II       26 March 1973

Bressler[1ページ]RFC478FTPサーバサーバ相互作用II1973年3月26日

                            +---------------+
                            |               |
                 +----------| USER PROCESS  |----------+
                 |          |       A       |          |
               telnet       +---------------+        telnet
                 |                                     |
                 |                                     |
          +-----------+                         +-------------+
          |           |-------->      --------->|             |
          |  SERVER   |data sockets  data socket|   SERVER    |
          |     B     |    Sb           Sc      |     C       |
          |           |<--------      <---------|             |
          +-----------+                         +-------------+

+---------------+ | | +----------| ユーザ・プロセス|----------+ | | A| | telnet+---------------+ telnet| | | | +-----------+ +-------------+ | |-------->。--------->|、|、| サーバ|データソケットデータソケット| サーバ| | B| Sb Sc| C| | | <、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、--、|、| +-----------+ +-------------+

   USER A TO SERVER B                     USER A TO SERVER C
   __________________                     __________________

サーバCへのサーバBユーザAへのユーザA__________________ __________________

   A->B   SOCK  HOST-C  SKT- Sc           A->C   SOCK  HOST-B  SKT-  Sb

Cを接待している1>のBソックスのSKT Sc1>のCソックスBを接待しているSKT- Sb

   B->A       ACK                         C->A      ACK

B>A ACK C>A ACK

   A->B   PASV

1>のB PASV

   B->A       ACK

B>A ACK

   A->B   STOR                            A->C   RTRV

1>のB STOR A>C RTRV

      1. After the PASV command has been acknowledged, the two data
         transfer commands can be sent in either order, since the
         LISTENING action takes place with the PASV command

1. PASVコマンドを承諾した後に、オーダーで2つのデータ転送コマンドを送ることができます、LISTENING動作がPASVコマンドで行われるので

      2. The user knows the socket numbers Sc and Sb to be the data
         sockets as specified by the protocol.

2. ユーザは、ソケット番号のScとSbが指定されるとしてプロトコルによるデータソケットであることを知っています。

      3. Note that it is not essential for a SOCK command to be sent to
         the same Host to whom a PASV will be sent.  Sending one to him
         provides security in that the incoming RFC can be checked.

3. PASVが送られるのと同じHostに送られるべきSOCKコマンドには、それが不可欠でないことに注意してください。 彼への発信1は、入って来るRFCをチェックできるので、セキュリティを提供します。

   RB/nlg

RB/nlg

          [This RFC was put into machine readable form for entry]
     [into the online RFC archives by Helene Morin, Via Genie 12/1999]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ヘレーネのモーリンによるオンラインRFCアーカイブへのVia Genie12/1999]

Bressler                                                        [Page 2]

Bressler[2ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

fasthalt システムを高速にシャットダウンする

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る