From f6d34d228eed54d5779a95c99e87248709afeda0 Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Thu, 30 Mar 2017 16:07:43 +0000 Subject: [PATCH] initial idea --- ...t___34__broadcasting__34___of_content_on_local_net.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/todo/multicast___34__broadcasting__34___of_content_on_local_net.mdwn diff --git a/doc/todo/multicast___34__broadcasting__34___of_content_on_local_net.mdwn b/doc/todo/multicast___34__broadcasting__34___of_content_on_local_net.mdwn new file mode 100644 index 0000000000..c2894ef8f9 --- /dev/null +++ b/doc/todo/multicast___34__broadcasting__34___of_content_on_local_net.mdwn @@ -0,0 +1,7 @@ +Hi Joey, + +Although you haven't remembered that "hash thing" to perform the job, we looked around for other ways to accomplish the mission: quickly/simultaneously distribute annexed files to multiple hosts on the same network. So, there are such tools as uftp to efficiently multicast files to multiple recipients. Initial setup takes a bit but I wondered how feasible it could be to e.g. establish some "custom annex remote" (if to avoid coming up with a new command eg. "annex serve") so e.g. I could e.g. `git annex copy --to=udp-multicast ` on the host A which has all the keys, and then run `git annex get --from=udp-multicast` on the clients (B) which want to get it all. To make it even more efficient, A could may be provide/announce on the local net a service to receive requests for desired keys to be transmitted. But even if it just multicasts all the content of the current tree, while those clients suck them all in, it could be super useful. + +What do you think? + +[[!meta name=yoh]]