2003-08-19 06:44:58 +00:00
|
|
|
<?
|
|
|
|
require_once("docutil.php");
|
|
|
|
page_head("Persistent file transfer");
|
|
|
|
echo "
|
2002-08-23 19:22:17 +00:00
|
|
|
<p>
|
2002-09-10 17:04:05 +00:00
|
|
|
A file upload or download may experience various types of
|
|
|
|
<b>transient failures</b>:
|
|
|
|
<ul>
|
|
|
|
<li> One or more data servers have failed.
|
|
|
|
<li> A network connection fails.
|
|
|
|
<li> The host PC is turned off or the core client quits.
|
|
|
|
</ul>
|
|
|
|
BOINC uses a mechanism called <b>persistent file transfer</b>
|
|
|
|
for efficiently recovering from these conditions,
|
|
|
|
and deciding when a <b>permanent failure</b> has occurred.
|
|
|
|
<p>
|
|
|
|
The FILE_XFER class encapsulates a single transfer session
|
|
|
|
to a particular data server.
|
|
|
|
If the file has previously partially transferred,
|
|
|
|
FILE_XFER resumes at the appropriate point.
|
2002-09-03 21:27:21 +00:00
|
|
|
<p>
|
2002-09-10 17:04:05 +00:00
|
|
|
The PERS_FILE_XFER class encapsulates a persistent file transfer,
|
|
|
|
which may involve a sequence of FILE_XFERs,
|
|
|
|
possibly to different data servers.
|
2002-09-03 21:27:21 +00:00
|
|
|
<p>
|
2002-09-10 17:04:05 +00:00
|
|
|
When a file is involved in a persistent file transfer,
|
|
|
|
the state is saved in the client state file
|
|
|
|
in the following XML element
|
2004-04-20 05:05:52 +00:00
|
|
|
(included in the <file_info> element):
|
2002-09-03 21:27:21 +00:00
|
|
|
<pre>
|
2002-09-10 17:04:05 +00:00
|
|
|
<persistent_file_xfer>
|
|
|
|
<num_retries>2</num_retries>
|
|
|
|
<first_request_time>1030665600</first_request_time>
|
|
|
|
<next_request_time>1030665725</next_request_time>
|
|
|
|
</persistent_file_xfer>
|
2002-09-03 21:27:21 +00:00
|
|
|
</pre>
|
|
|
|
<ul>
|
2002-09-10 17:04:05 +00:00
|
|
|
<li> The <b>num_retries</b> element is the number of
|
|
|
|
transfer sessions so far.
|
|
|
|
<li> The <b>first_request_time</b> element is the time
|
|
|
|
the first transfer session started.
|
2002-09-03 21:27:21 +00:00
|
|
|
<li> The <b>next_request_time</b> element is the earliest time
|
2002-09-10 17:04:05 +00:00
|
|
|
to start a new transfer session.
|
2002-09-03 21:27:21 +00:00
|
|
|
</ul>
|
|
|
|
<p>
|
2002-09-10 17:04:05 +00:00
|
|
|
When there is a transient failure, the core client
|
|
|
|
increments num_retries and calculates a new next_request_time
|
|
|
|
based on randomized exponential backoff, given by
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
next_request_time = current_time+max(MIN_DELAY,min(MAX_DELAY,exp(rand(0,1)*num_retries)))
|
|
|
|
</pre>
|
2002-09-03 21:27:21 +00:00
|
|
|
Where MIN_DELAY is 1 minute and MAX_DELAY is 4 hours.
|
|
|
|
<p>
|
2002-09-10 17:04:05 +00:00
|
|
|
The client classifies the transfer as a permanent failure if the
|
2002-09-03 21:27:21 +00:00
|
|
|
current time becomes much later than this (default is two weeks).
|
2002-09-10 17:04:05 +00:00
|
|
|
|
|
|
|
??? later than what?
|
|
|
|
|
2002-09-03 21:27:21 +00:00
|
|
|
In this event, the file will be deleted and the failure reported
|
|
|
|
to the scheduling server.
|
2002-09-10 17:04:05 +00:00
|
|
|
|
2003-08-19 06:44:58 +00:00
|
|
|
??? in what form?
|
|
|
|
";
|
|
|
|
page_tail();
|
|
|
|
?>
|