David, I think that the following might be the way to go:
When the BOINC client is downloading any file and the transfer is interrupted, then it should check for the existence of the "Accept-Ranges: bytes" header for that file transfer. If that header is found, then the client behavior remains unchanged. If that header is not found, then the client should not save any partially downloaded file. It should delete it and during the next request it should request the entire file. The example code associated with this article: http://www.linuxdevcenter.com/pub/a/linux/2005/05/05/libcurl.html contains info on how to get the request headers. This will resolve our issues. However, the boinc client has this code in http_curl.cpp: if ((response/100)*100 == HTTP_STATUS_OK) { http_op_retval = 0; } else if ((response/100)*100 == HTTP_STATUS_CONTINUE) { return; } else { This is essentially converting all of the 2XX response codes to be the same as HTTP_STATUS_OK. The 200 vs 206 response code is therefore being treated the same by the BOINC code. I think that the BOINC client should handle the 200 and 206 return codes differently and if 200 is returned then the file downloaded should replace any existing file. If 206 is returned, then the client should append to any existing file. These behaviors would allow the client to operate as expected with regards to HTTP headers and response codes. This also does give control of the client behavior on the server side as the presence or absence of the 'Accept-Ranges' header would control what the client did. In the interim, I will modify our server so that it it ignores the Ranges request header and does not contain the Accept-Ranges response. This will cause the entire file to be returned. Since the BOINC client will append this to the existing partial file, it will fail the md5sum check. However, that will result in an immediate failure instead of it taking waiting for the timeout like it is doing now. Once users start using the 6.10 client, then the behavior will work as desired. thanks, Kevin |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |David Anderson <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Kevin Reed/Chicago/i...@ibmus | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Carl Christensen <[email protected]>, BOINC Developers Mailing List <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |06/22/2009 11:08 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [Fwd: [BOINC] #924: Partial Transfer Fails] | >--------------------------------------------------------------------------------------------------------------------------------------------------| It seems like any solution is going to involve a client change. So what about my previous suggestion, namely a <no_partial_transfer> flag in the <file_info>. That would provide control at the server side, which is desirable. -- DPA Carl Christensen wrote: > I don't think libcurl distinguishes between a 206 & 200 (from this message I > found from the main libcurl guy, although it's a two-year old thread): > > http://curl.haxx.se/mail/lib-2007-05/0011.html > > it seems safer to just not let curl try to compress/decompress (i.e. no gzip > in content headers) and treat it as any file (which can handle the resumable > downloads) and then just decompress by the app after the file is successfully > downloaded. > > Carl Christensen [email protected] http://www.geocities.com/carlgt1 > > > >
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
