design

doc/todo/multicast___34__broadcasting__34___of_content_on_local_net/comment_1_5353dc46ccecc6077f2643d281d58f99._comment

@@ -0,0 +1,91 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-30T16:51:24Z"
+ content="""
+Using a remote for this seems problimatic, because the remote is not
+pointing at a single well-defined data store, but instead whatever peers
+happen to exist on the network.
+
+For one, `copy --to=udp-multicast` would not try to send files that it thinks
+are already located in that remote. I suppose this could be dealt with by
+making the transfers always seem to fail, so it never thinks that the
+multicast remote has any files.
+
+But then, `copy --from=udp-multicast` would not try to receive files,
+unless it thinks they're in that remote. And we just established it should
+not think any files are in that remote. So that's a problem.
+
+Also, the copy from/to would need to be operating on the same file at the
+same time, which seems problimatic. If a receiving git-annex is a little
+slower than the sender, or is operating on a slightly different set of
+files, it would then miss a file being broadcast by the sender.
+
+These issues seem to point to this needing to use some other, more
+special-purpose commands for muticast.
+
+----
+
+It probably needs encryption, both for privacy and to ensure that files
+are being received from the sender you intended, and not someone else
+who might be broadcasting the contents of a different repository.
+
+Here's how to set up encryption and authentication with uftp,
+so that both client and server actually encrypt and check that they're
+talking with a known entity. It took a while to figure out.
+
+Client:
+
+	uftp_keymgt -g rsa:512 ~/client_key
+	# Parse the fingerprint value from its output; does not
+	# seem to be a better way, except perhaps using openssl to examine
+	# the key file. This is CLIENT_FINGERPRINT
+
+	# Pick a UID for the client. This is an 8-diget hex number,
+	# which needs to be unique across clients. Default is based on IP
+	# adddres, but for git-annex it could be derived from the git-annex
+	# UUID.	This is CLIENT_UID.
+
+Server:
+
+	uftp_keymgt -g rsa:512 ~/servant_key
+	# Parse the SERVER_FINGERPRINT from its output.
+	
+	# Pick a SERVER_UID for the server.
+
+Client:
+
+	# create a file "authlist" that contains "$SERVER_UID|$SERVER_FINGERPRINT"
+
+	uftpd -E -d -D/tmp/xx -k ~/client_key -U $CLIENT_UID -S '@authlist'
+
+Server:
+
+	# create file "authlist" that contains "$CLIENT_UID|$CLIENT_FINGERPRINT"
+	# lines for each allowed client
+
+	uftp -c -Y aes256-cbc -h sha1 -k ~/server_key -U $SERVER_UID -H '@authlist' file_to_send
+
+----
+
+Notice that the client and server UID and key generation steps above 
+are the same. So, a command like `git annex multicast --gen-address`
+could be run on both the server and clients, and could store
+the addresses in the git-annex branch. 
+The uftp authlist file would be derived from all known such addresses.
+
+(Unlike `p2p --gen-address`, where the address allows connecting with
+and authentication with a remote over TOR, these multicast addresses
+are safe to make public.)
+
+The process of setting up a multicast classroom would then be:
+
+1. Teacher runs `git annex multicast --gen-address; git annex sync`
+2. Students each run `git annex multicast --gen-address; git annex sync`
+3. Teacher runs `git annex sync` once all the students have generated addresses.  
+   (Now the students all have received the teacher's address, and the teacher
+   has received all the student's addresses.)
+4. Students each run `git annex multicast-receive`, which listens for 
+   files going by and stores them.
+5. Once the students are listening (*ahem*), teacher runs
+   `git annex multicast-send [file]` to distribute files.