From allcock at alcf.anl.gov  Mon Dec 21 17:09:18 2009
From: allcock at alcf.anl.gov (William (Bill) E. Allcock)
Date: Mon, 21 Dec 2009 17:09:18 -0600
Subject: [Gridftp-wg] data receiver behavior on unexpected close of
	network connection?
In-Reply-To: <4961E154-41EF-4B65-B35D-AD4396A51079@fnal.gov>
References: <4961E154-41EF-4B65-B35D-AD4396A51079@fnal.gov>
Message-ID: <BFBDDE71-EA76-4565-B731-DEBF543EC9E0@alcf.anl.gov>

Matt,

The GridFTP WG is dormant.  You should probably send this to one of  
the globus GridFTP lists.  To the best of my knowlege, the answer to  
your question is that the protocol document does not define that.  it  
is purely a wire protocol description.  In MODE E, at least you can  
tell if the file is complete or not, but in stream mode (standard FTP)  
you can't tell if you got all the data or not before the RST or ABOR.   
This ambiguity is a well known problem and some of the later revisions  
to the GridFTP protocol tried to address that to some extent.  Not  
surprisingly, that was largely driven by Fermi lab folks (Igor  
Mandrichenko).

Bill
On Dec 3, 2009, at 4:12 PM, Matt Crawford wrote:

> I cannot find any specification of the correct behavior of a gridftp  
> client which is the receiver of a file transfer when there is a TCP  
> RST on a data stream or an unexpected close (or a user ABOR command)  
> on the data channel.
>
> Should any partial data file be deleted? If so, where is that written?
>
>
>
>                Matt Crawford   <crawdad at fnal.gov>
>                Fermilab Data Movement and Storage
>                +1 630 840 3461
>
>
>

--------------------------------------------------------------
William (Bill) E. Allcock
allcock at alcf.anl.gov
Office 1123, Bldg 240
9700 S. Cass Ave
Argonne, IL 60439
Office: 630-252-7573
Fax: 630-252-6585
Cell: 630-854-2842

The test of courage comes when we are in the minority.
The test of tolerance comes when we are in the majority.
   - Ralph W. Sockman