Subject: draft-bryan-ftp-hash-02 experimental client implementation

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 15 May 2010 10:42:44 +0900

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

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 15 May 2010 21:19:10 +0200 (CEST)

On Sat, 15 May 2010, Tatsuhiro Tsujikawa wrote:

> 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.

Surely any client will expect ocasional very long delays from ordinary 
commands just due to slow/loaded servers and huge network delays? Exactly what 
kind of delay are you talking about here?

And BTW, there's nothing in the proposal that prevents a server from 
responding with a non-final "progress" line from the server informing the 
client that it is calculating the hash, is it?

-- 

  / daniel.haxx.se

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sun, 16 May 2010 18:22:52 +0900

Hi,

(05/16/10 04:19), Daniel Stenberg wrote:
> commands just due to slow/loaded servers and huge network delays?
> Exactly what kind of delay are you talking about here?
>

I mean the delay during hash calculation by the server.
If client knows the delay is actually caused by calculation of hash, it 
can wait for the response of the server beyond of timeout.

> responding with a non-final "progress" line from the server informing
> the client that it is calculating the hash, is it?
>

Ah, yes, "progress" line can help here.

Best regards,

Tatsuhiro Tsujikawa