Client needs to cancel transfer after server abort

[Richard Haselgrove]

SETI@home has implemented 'Redundant result - Cancelled by server' technology - if a quorum is filled and work validated, messages are sent to host(s) with the same WU 'abort if not started'.

During outage recovery on a busy/short WU project like SETI, it is possible that a WU can be validated and assimilated while the third quorum member (me, in this case!) is still trying to download the datafile through congestion/backoffs.

After assimilation, the datafile is quite properly deleted from the server download fanout, and the host's transfer is doomed to fail forever with 'file not found' retrys.

Once the host gets into this state, it seems to inhibit all work fetch for that project, until the offending transfer is aborted by user intervention. It will rapidly run dry.

When the server abort is issued and acted upon, presumably there are two actions:

1) Remove from task list after report 2) Delete datafile from disk

There needs to be a third:

3) Cancel any pending transfer for the datafile

[jason_gee]

---

This happened to one of my hosts. Project aborted result, leaving it in the download queue. Endless server retries resulted, and refusal to get more work until transfer manually aborted.
jason_gee

---

[davea]

(In [17486]) - client: change garbage-collect logic.

old: reference-count files involved in a PERS_FILE_XFER new: if a PERS_FILE_XFER refers to an unreferenced file,

delete it (and the associated FILE_XFER and HTTP_OP if present)

May fix #366

[romw]

(In [17493]) - client: change garbage-collect logic.

old: reference-count files involved in a PERS_FILE_XFER new: if a PERS_FILE_XFER refers to an unreferenced file,

delete it (and the associated FILE_XFER and HTTP_OP if present)

May fix #366

client/

client_state.cpp