Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

FTP server-server interaction (RFC0438)

IP.com Disclosure Number: IPCOM000004924D
Original Publication Date: 1973-Jan-15
Included in the Prior Art Database: 2001-Jul-12
Document File: 4 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Thomas: AUTHOR [+2]

Abstract

The current ARPANET File Transfer Protocol as specified by RFC 354 and updated by RFC's 385, 414 and 418 allows for "third host" participation but does not specify a mechanism by which the process at the third site may be the FTP server at that site. This RFC suggests a simple extension to FTP which would allow an FTP user process at one site to arrange for FTP server processes at other sites to act cooperatively on its behalf.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 55% of the total text.

Network Working Group B. Thomas Request for Comments: 438 B. Clements NIC: 13770 BBN-TENEX References: 354,385,414,418 15 January 1973

FTP Server-Server Interaction

The current ARPANET File Transfer Protocol as specified by RFC 354 and updated by RFC's 385, 414 and 418 allows for "third host" participation but does not specify a mechanism by which the process at the third site may be the FTP server at that site. This RFC suggests a simple extension to FTP which would allow an FTP user process at one site to arrange for FTP server processes at other sites to act cooperatively on its behalf.

Such server-server cooperation may appear to be of limited utility. Consider, however, the requirements placed on FTP by a Resource Sharing Executive (RSEXEC) program a command language interpreter which extends the range of a user's commands beyond the boundaries of the user's local system. Among its services such as RSEXEC could provide its users with a network-wide file system, perhaps allowing, in certain contexts, the use of partially qualified pathnames which omit site specification. Consider, for example the response of the RSEXEC to the user command:

APPEND (FILE) PROG1.PL1 (TO FILE) PROG2.PL1

for the case in which the two files are at different sites (PROG1.PL1 at SITE1, PROG2.PL1 at SITE2) neither of which is the user's site. A straightforward way for the RSEXEC to "perform" the APPEND would be to establish FTP control connections to the FTP servers at SITE1 and at SITE2, instruct the server at SITE1 to

RETR PROG1.PL1

using data connection C and instruct the server at SITE2 to

APPE PROG2.PL1

using the same data connection C.

Unfortunately, at present there is no way within FTP to arrange for such server-server cooperation. This is due primarily to the lack of symmetry in the way that FTP treats the ends of data connections during connection establishment. It specifies one end to be the "server" end, the other to be the "user" end and specifies different means for establishing the connections from the two ends.

Thomas, et. al. [Page 1]

RFC 438 FTP Server-Server Interaction January 1973

FTP could be modified to support server-server interaction by:

1. making the establishment of data connections symmetric, or;

2. providing a mechanism for instructing a server to establish its

end of a data connection as if it were a user.

The second alternative probably requires fewer changes to the existing protocol.

The following proposed extension to FTP uses the second method. It involves the addition of a single new command (LSTN) and minor modifications to several existing commands (SOCK, APPE, RETR, STOR):

a. The LSTN (Listen) command requests the FTP server to allocate a socket for use as a data connection. To establish the corresponding data connection the server is to "listen" on the socket allocated when an ...