draft-bryan-ftp-hash-02 experimental client implementation
Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Sat, 15 May 2010 01:43 UTC
Return-Path: <tatsuhiro.t@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C633A6802 for <apps-discuss@core3.amsl.com>; Fri, 14 May 2010 18:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-qKL0jMylyO for <apps-discuss@core3.amsl.com>; Fri, 14 May 2010 18:42:59 -0700 (PDT)
Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 2F31D3A67FC for <apps-discuss@ietf.org>; Fri, 14 May 2010 18:42:59 -0700 (PDT)
Received: by pzk38 with SMTP id 38so294916pzk.31 for <apps-discuss@ietf.org>; Fri, 14 May 2010 18:42:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=bN1Exr2mwrHoC6hZ3oW3q6lLhnhxNWQYZLWQtTEZh2U=; b=I1JYaqQpiRcmAEn35jgDhK1baqUfk8/D1zYANiWh+Rs3iNBdO1kZVc20Qp14rU827r sWVhv7DQURYH0GK1aUjBbQ8QyROOVMl+gek+lfSK2JeksBg58BEfdj28t/0gtCC5j6uU r63Y/YiETWhzhp4RpLSyxpzoBLMq2bxEBQmag=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=NM+4kvAhOfwvofQNTMB5En7nBN0rkyYhmzKSbpRQFmu3FjoQEKSRs+P5mZlVlCdM1n ZeI0IBgORAddD162xVOC8FxOCApCC1cmq2kPmgutGuLutTXSdSbofNTJMJHr6bKelGTZ 2qxkt+MijV9vCJWhkvCQbL4y1si8ruqc4nhoQ=
Received: by 10.142.120.26 with SMTP id s26mr1278951wfc.141.1273887767561; Fri, 14 May 2010 18:42:47 -0700 (PDT)
Received: from [192.168.0.11] (kng29-p43.flets.hi-ho.ne.jp [121.102.202.43]) by mx.google.com with ESMTPS id 20sm2133938pzk.15.2010.05.14.18.42.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 18:42:46 -0700 (PDT)
Message-ID: <4BEDFC14.1010008@gmail.com>
Date: Sat, 15 May 2010 10:42:44 +0900
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100411 Icedove/3.0.4
MIME-Version: 1.0
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: draft-bryan-ftp-hash-02 experimental client implementation
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 May 2010 01:43:00 -0000
Hi, I created client implementation of draft-bryan-ftp-hash-02 using aria2 codebase. I tested with Tim's experimental FileZilla Server build. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01481.html Svn repository: http://aria2.svn.sourceforge.net/viewvc/aria2/branches/draft-bryan-ftp-hash/ Source tar ball (Google docs): http://docs.google.com/leaf?id=0B8qYMk_Gn7y6NDllYWQ2MGItMzM3Zi00MjIzLWE4MGMtZmNlMWVmOGNiODc5&hl=en Win32 binary (Google docs): http://docs.google.com/leaf?id=0B8qYMk_Gn7y6NjhhMzNjNDgtMzY4NC00ODhmLTg5YTEtZGFiZmY2MThjOTI5&hl=en While I was implementing draft, I wonder whether there is long delay before the response of hash command, because of calculation of hash in server side. For clients, especially automated ones, have some kind of timeout and if timeout reaches while server does not respond, they assume that connection is lost or something bad happened and drop session. Since hash response only appears when hash is calculated, clients cannot know the difference of hash calculation delay or some other network problem. Best regards, Tatsuhiro Tsujikawa
- draft-bryan-ftp-hash-02 experimental client imple… Tatsuhiro Tsujikawa
- Re: draft-bryan-ftp-hash-02 experimental client i… Daniel Stenberg
- Re: draft-bryan-ftp-hash-02 experimental client i… Tatsuhiro Tsujikawa