Rsync over DTN
This page describes how to use the DTN2 reference implementation and utilities to run an rsync process over a network of DTN routers.
To do so, the dtntunnel application is used to set up a TCP proxy between two hosts over the DTN network. Then, by configuring rsync to communicate over this tunneled port, the DTN overlay network transmits all data between the two hosts (through any number of intermediate hops), and the rsync processes communicate directly with dtntunnel on both ends.
Rsync can be run in a wide range of configurations and options -- this example will show two such cases, one in which rsync is running over ssh, and one using the rsync protocol to contact an rsync process running in daemon mode.
Network Description
For simplicity, this example will assume there are two machines, 'alice.some.domain' and 'bob.some.domain', both of which are directly accessible on the Internet (i.e. no NAT or firewalls that interfere). Both hosts have a directory to be synchronized to the other host, called /alice_data and /bob_data respectively.
To demonstrate both pushing and pulling directory contents, we will run the rsync client only on host alice, once to send the contents of /alice_data to the corresponding directory on host bob and then again to pull the contents of /bob_data from host bob back to alice.
When running over DTN, we also run a 'dtntunnel' instance on bob in listening mode and a 'dtntunnel' instance on alice in proxy mode. The specific configuration for each is described below. The rsync client is then run on alice, configured to connect to the tunnel proxy instead of to host bob.
Setting up the DTN Network
Since there are only two hosts in the network, the 'dtnd' processes on both hosts are configured with direct connections between the two hosts, using the TCP convergence layer.
The relevant configuration to set up a bidirectional link and associated routing between the two is:
On alice:
route local_eid dtn://alice.dtn link add l-bob bob.some.domain:4556 ALWAYSON tcp remote_eid=dtn://bob.dtn
On bob:
route local_eid dtn://bob.dtn route set add_nexthop_routes true
Because the TCP convergence layer is bidirectional, alice will initiate a connection to bob when 'dtnd' is started. When the connection is accepted by bob, 'dtnd' will create an opportunistic link back to alice. The add_nexthop_routes configuration option will add a route for dtn://alice.dtn/* to use this link for all return bundle traffic.
To test that this configuration works, run dtnd on both alice and bob after storing the configuration changes (typically in /etc/dtn.conf). Then you should be able to run
dtnping dtn://bob.dtn/ping
on alice and see the ping bundles returned from bob appropriately.
Mode 1: rsync over ssh over dtn
The first mode of running rsync over DTN will still use ssh for authentication and transport, but will tunnel the ssh connection over DTN.
If one were using rsync over ssh directly (i.e. without DTN), this would be accomplished by running the following on host 'alice':
rsync -e "ssh" -rav /alice_data/ bob:/alice_data/ rsync -e "ssh" -rav bob:/bob_data /bob_data
Running the dtntunnel proxy
On bob, run:
dtntunnel -L
On alice, run:
dtntunnel -T 10022:localhost:22 dtn://bob.dtn/dtntunnel
In this way, we set up a tunnel so that TCP connections on alice to port 10022 are proxied via the dtntunnel client to the DTN daemon. Similar to regular SSH port forwarding, alice's dtntunnel will only listen on loopback by default, though this can be overridden.
The bundles are routed over DTN to bob's dtntunnel listener application, which by default registers on the endpoint id dtn://bob.dtn/dtntunnel. When the TCP tunnel bundles arrive at the dtntunnel listener application, the application will forward the bundles to TCP port 22 on host bob, where 'sshd' is listening.
Running the rsync client
On alice, run:
rsync -e "ssh -p 10022" -rav /alice_data/ localhost:/alice_data/ rsync -e "ssh -p 10022" -rav localhost:/bob_data /bob_data
Note the similarity between these commands and the non-tunneled rsync commands above. The differences are that the ssh command is changed to use port 10022 and the "remote" host is changed to localhost so that it connects to the dtntunnel proxy rather than directly connecting to bob.
Mode 2: using the rsync protocol
Although the rsync over ssh method is the simplest to configure, it is less efficient when running over a poor-quality network because ssh requires several round trips to authenticate the connection. Instead, rsync can also operate using its own protocol over TCP, with a separate optional authentication mechanism.
Setting up the rsync daemon
As with the rsync client, there are many different configuration options for the rsync daemon (see the man page for rsyncd.conf).
A trivial configuration file without any authentication that suffices for this example is the following:
[alice_data]
dir = /alice_data
read only = false
[bob_data]
dir = /bob_dataSave this configuration file in /etc/rsyncd.conf and then run:
rsync --daemon
as root.
Running the dtntunnel proxy
Just as in the first example, on bob, run:
dtntunnel -L
On alice, this time we proxy localhost port 10873 to the rsync port (873) so run the following:
dtntunnel -T 10873:localhost:873 dtn://bob.dtn/dtntunnel
Running the rsync client
On alice, run:
rsync -rav --port=10873 /alice_data/ rsync://localhost/alice_data/ rsync -rav --port=10873 rsync://localhost/bob_data /bob_data