IETF Logo Mail Archive

Re: [ftpext] COMB command IETF draft proposal

Richard Koenning <Richard.Koenning@ts.fujitsu.com> Fri, 10 June 2011 13:07 UTC

Return-Path: <Richard.Koenning@ts.fujitsu.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 41D4911E8130 for <ftpext@ietfa.amsl.com>; Fri, 10 Jun 2011 06:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 9ml800UL5i7t for <ftpext@ietfa.amsl.com>; Fri, 10 Jun 2011 06:07:08 -0700 (PDT)
Received: from dgate20.ts.fujitsu.com (dgate20.ts.fujitsu.com [80.70.172.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1689B11E80F8 for <ftpext@ietf.org>; Fri, 10 Jun 2011 06:07:07 -0700 (PDT)
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Reply-To:Organization: User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=n7OtuyAFtqe61y0JRQMH071OmhKrTQPNs3BAmfleSLzu0+QIL1jkuOwR jsuQu4B1k8CzDnMHiH52jhUhqUCArituYKWZQE5GFgkIqqxQN4326Ejpc 2mX687RbzXIEeEQ7Fm5WMqP3YMmU1t0P6pAAyrglaM0D5gyv8dCm9kUd2 cwqoI9zk0kFANmdHz1swwcUZXMJR8w2gQCkh2ajeCwBrApw/WCiZyAsWe udS+l+0soaoj7Ypr56bnJRxnwYA37;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=Richard.Koenning@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1307711228; x=1339247228; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NOsvqGWEcWaoBzUKe2jrnT9QuPsYsshMEmEdv1K9XEc=; b=FcamLizfzEs+uNoqnIRACm5SNUzfD7K6ybDf45MV3fuAM0rglXJO3aCs 3awma5ie460K//J5SmluAsMr1D+XSFBXaa22AbfSEZXXSxr5aPftwSOjd b8KojIUe7O5s4QJLY5a5lbBuwMyx3qxCzH82BqhXYJzsDp2DjKquIiAI0 uQ7G3LPYgcSOUsR8iq3/IBi2h1Iex9Ob5dnCruaVHk64c7pIVS47DYYP4 0eYh5ScUnI8G87oro9yPMmnaTGP5C;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.65,346,1304287200"; d="scan'208";a="67710918"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66]) by dgate20u.abg.fsc.net with ESMTP; 10 Jun 2011 15:07:06 +0200
X-IronPort-AV: E=Sophos;i="4.65,346,1304287200"; d="scan'208";a="114138366"
Received: from mch8469d.mch.fsc.net (HELO [172.25.52.240]) ([172.25.52.240]) by abgdgate30u.abg.fsc.net with ESMTP; 10 Jun 2011 15:07:06 +0200
Message-ID: <4DF216F9.5000205@ts.fujitsu.com>
Date: Fri, 10 Jun 2011 15:07:05 +0200
From: Richard Koenning <Richard.Koenning@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: de, de-nds, en, en-US, it
MIME-Version: 1.0
To: "ftpext@ietf.org" <ftpext@ietf.org>
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>
In-Reply-To: <F15941D3C8A2D54D92B341C20CACDF2311AC51B892@exchange>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: Robert Oslin <rto@globalscape.com>
Subject: Re: [ftpext] COMB command IETF draft proposal
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Richard.Koenning@ts.fujitsu.com
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:07:09 -0000

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

v2.23.0 | Report a Bug | By Email