Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

A Method and Apparatus for Improving the Reliability of Items Transferred using File Transfer Protocol.

IP.com Disclosure Number: IPCOM000129859D
Original Publication Date: 2005-Oct-07
Included in the Prior Art Database: 2005-Oct-07
Document File: 3 page(s) / 54K

Publishing Venue



Transactional File Transfer (FTP)

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 38% of the total text.

Page 1 of 3

A Method and Apparatus for Improving the Reliability of Items Transferred using File Transfer Protocol.

The internet provides the ability to transfer files from one computer to another using the File Transfer Protocol (FTP).

    Files transferred using FTP copy a source file (on whatever computer and formatted according to the locale of that computer) to a destination (on another, or the same) computer with a potentially different locale. The file can either be transferred without any locale conversion (natively, conventionally using the BIN option) or with locale conversion (conventionally using the TXT option). This latter TXT methodology converts the contents of the file into a format acceptable for the destination computer. For example, a common case is where a human readable text file is converted from the IBMMainframe EBCDIC notation into the ASCII representation commonly used on a personal computer.

FTP operations are conventionally divided into two parts: * The Client portion which initiates the transfer operation and generally handles user interaction including issuing the commands which initiate the transfer of a file * The Server portion which typically runs on the destination computer and does the updating of the files (or provides the files in the case of a read operation) amongst other operations

    A FTP Client generally obtains files from a FTP Server by use of the GET operation, and similarly transmits files to be replaced on the destination computer by issuing the PUT verb. The files can be renamed for each operation.

    However, when a file is being transferred using FTP, corruption will occur on the destination computer if the file is not wholly successfully transferred. For example, if the connection between the two computers is lost during the transfer of the file, the copied file on the destination computer is not complete. This has the unfortunate result that, if the FTP operation is proceeding without the benefit of human operation, the corruption may not be detected until the file is being attempted to be used for real. Indeed, if the file is accessed randomly (not sequentially) - perhaps via some sort of keyed access mechanism - the corruption may not be observed. In this circumstance, the corruption may not be observed for a large period of time after it initially occurred, and so applications using the file may potentially become invalid, or lost, until the corruption is detected and removed.

    Even worse, a group of files may logically need to be transferred together. A partial exchange would result in an invalid environment, and so result in a corrupt application or an application which does not work because of inconsistent data. FTP processing typically continues to transfer data even if a file in such a sequence fails to correctly transfer. Further, some types of corruption are subtle enough so that, from the standpoint of an application using a corrupt file, no erroneous data is present/absent.