aboutsummaryrefslogtreecommitdiff
path: root/doc/devblog/day_92-93__reconnection.mdwn
blob: aa83bde38c3145a3cc39a5035a37f41ef95a1626 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Yesterday, added per-remote, per-key state storage. This is exported via
the external special remote protocol, and I expect to use it at least for
Tahoe Lafs.

Also, made the assistant write ssh config files with better permissions,
so ssh won't refuse to use them. (The only case I know of where that
happened was on Windows.)

Today, made `addurl` and `importfeed` honor annex.diskreserve. Found out about
this the hard way, when an importfeed cron job filled up my server with
youtube videos. I should probably also make `import` honor
annex.diskreserve.

---

I've been working, so far inconclusively, on making the assistant
deal with remotes that might open a long duration network connection.
Problem being that if the connection is lost, and the remote is not smart
enough to reconnect, all further use of it could fail.

In a `restarttransferrer` branch, I have made the assistant start separate
`transferkeys` processes for each remote. So if a remote starts to
fail, the assistant can stop its `transferkeys` process, and restart it,
solving the problem.

But, if a resource needed for a remote is not available, this degrades to
every transfer attempt to that remote restarting it. So I don't know if this is the
right approach.

Other approaches being considered include asking that implementors of
external special remotes deal with reconnection themselves (Tobias, do you
deal with this in your remotes?), or making the
assistant only restart failing remotes after it detects there's been 
a network connection change.