summaryrefslogtreecommitdiff
path: root/doc/devblog/day_92-93__reconnection.mdwn
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2014-01-04 18:15:06 -0400
committerGravatar Joey Hess <joey@kitenet.net>2014-01-04 18:15:06 -0400
commitcb29393c83de9255109769d7b9c4b5b0f2d26bcc (patch)
treef5b272648e48ca70f9b22024864565beff475e52 /doc/devblog/day_92-93__reconnection.mdwn
parent10e19240ce1ae19604cc5edaee875174cabcced6 (diff)
devblog
Diffstat (limited to 'doc/devblog/day_92-93__reconnection.mdwn')
-rw-r--r--doc/devblog/day_92-93__reconnection.mdwn34
1 files changed, 34 insertions, 0 deletions
diff --git a/doc/devblog/day_92-93__reconnection.mdwn b/doc/devblog/day_92-93__reconnection.mdwn
new file mode 100644
index 000000000..aa83bde38
--- /dev/null
+++ b/doc/devblog/day_92-93__reconnection.mdwn
@@ -0,0 +1,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.