Re: [ftpext] COMB command IETF draft proposal

Robert Oslin <rto@globalscape.com> Fri, 10 June 2011 13:53 UTC

Return-Path: <rto@globalscape.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65311E817F for <ftpext@ietfa.amsl.com>; Fri, 10 Jun 2011 06:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.476
X-Spam-Level:
X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocndt6IfL0SS for <ftpext@ietfa.amsl.com>; Fri, 10 Jun 2011 06:53:55 -0700 (PDT)
Received: from exchange.globalscape.com (exchange.globalscape.com [208.89.186.62]) by ietfa.amsl.com (Postfix) with ESMTP id CC37C11E8135 for <ftpext@ietf.org>; Fri, 10 Jun 2011 06:53:54 -0700 (PDT)
Received: from exchange.forest.intranet.gs ([127.0.0.1]) by exchange2.forest.intranet.gs ([fe80::ccf3:ac5c:2f5e:19d5%10]) with mapi; Fri, 10 Jun 2011 08:53:53 -0500
From: Robert Oslin <rto@globalscape.com>
To: "Richard.Koenning@ts.fujitsu.com" <Richard.Koenning@ts.fujitsu.com>, "ftpext@ietf.org" <ftpext@ietf.org>
Date: Fri, 10 Jun 2011 08:53:52 -0500
Thread-Topic: [ftpext] COMB command IETF draft proposal
Thread-Index: Acwnb04vTn2dgvCRSG6+1hnAuci3jQABbSYQ
Message-ID: <F15941D3C8A2D54D92B341C20CACDF2311AC51B97F@exchange>
References: <F15941D3C8A2D54D92B341C20CACDF2311AC408AB1@exchange> <01AA9EC92749BF4894AC2B3039EA4A2C1946D58A@CH1PRD0302MB131.namprd03.prod.outlook.com> <F15941D3C8A2D54D92B341C20CACDF2311AC51B359@exchange> <BANLkTina+ZF97cgQrJp7yGWcsWmY4eOuEQ@mail.gmail.com> <F15941D3C8A2D54D92B341C20CACDF2311AC51B3C4@exchange> <4DF07777.2010205@kimmeringer.de> <4DF0E42F.1000104@ts.fujitsu.com> <4DF11952.6060601@kimmeringer.de> <F15941D3C8A2D54D92B341C20CACDF2311AC51B725@exchange> <4DF14059.9080709@kimmeringer.de> <F15941D3C8A2D54D92B341C20CACDF2311AC51B892@exchange> <4DF216F9.5000205@ts.fujitsu.com>
In-Reply-To: <4DF216F9.5000205@ts.fujitsu.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [ftpext] COMB command IETF draft proposal
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jun 2011 13:53:55 -0000

I totally missed/forgot about that: "The server-FTP process may send at most, one 1yz reply per command.", which again gives favor to the argument that the client app should take care of / handle timeouts, which can be done through configuration by the user or by adapting timeout thresholds dynamically. 

We should still include a recommendation (using "SHOULD") that the server offer up a (single) 1xx reply at some point in the combine process, but even so this (timeouts) may not be a problem if the server is "smart" about how it combines the file upon receipt.

Thanks,

Robert Oslin

-----Original Message-----
From: Richard Koenning [mailto:Richard.Koenning@ts.fujitsu.com] 
Sent: Friday, June 10, 2011 8:07 AM
To: ftpext@ietf.org
Cc: Robert Oslin; Lothar Kimmeringer
Subject: Re: [ftpext] COMB command IETF draft proposal

As Van Glass already pointed out in an answer to his own similar proposal only one 1yz message is allowed per command (see RFC 959, p.37). Even when RFC 959 is not engraved into stone one should think twice before violating/changing rules layed down in this RFC.
Best regards,
Richard

Robert Oslin wrote:

> " So if the server is working sequntially it might give out some kind of information that helps seeing some progress, but it might be something completely different like a poem ;-)"
> 
> Agreed. Sending the 150 at regular intervals (and not dependent on some predetermined event, such as part1 combined), would work nicely.
> 
> A server NOOP if you will.
> 
> Robert
> 
> 
> -----Original Message-----
> From: Lothar Kimmeringer [mailto:lothar@kimmeringer.de]
> Sent: Thursday, June 09, 2011 4:51 PM
> To: Robert Oslin
> Cc: Richard.Koenning@ts.fujitsu.com; ftpext@ietf.org
> Subject: Re: [ftpext] COMB command IETF draft proposal
> 
> Am 09.06.2011 21:10, schrieb Robert Oslin:
> 
>>This assumes one method of recombining the file where each part is 
>>sequentially
> 
>  > tacked on to the next, e.g. open, seek, write, open, seek, write, ad nauseam.
>  > There are likely OS and File System specific techniques for combining multiple  > chunks (parts) into a single file that may only be able to provide an all or  > nothing "finished" vs. a partial success for each chunk appended in a sequential  > write operation. I'll provide more on that in a bit (currently writing my reply  > to the various comments)...
> 
> What the specific text after "150-" doesn't matter, it can also be 150-I'm still here, please wait or whatever you (the server) want. The only important thing is that something is given out at all that allows to reset the timeout on the client side.
> 
> So if the server is working sequntially it might give out some kind of 
> information that helps seeing some progress, but it might be something 
> completely different like a poem ;-)
> 
> In principle this technique is already in use, e.g. with "tarpits"
> (http://en.wikipedia.org/wiki/Tarpit_%28networking%29).
> 
> 
> Regards, Lothar


--
Dr. Richard W. Könning
Fujitsu Technology Solutions GmbH