Hacker News Reader

Comment by Arnavion | Hacker News Reader

Use your client to create a .torrent. Send the .torrent over. Other party adds your IP as a seed. No trackers or DHT required.

View on HN

Unfortunately, I've never managed to get this to work, even though the two computers have open ports and can connect to each other via nc/telnet. The other peer m just never starts downloading when I seed the file.

BitTorrent is a fantastic way to transfer files, except for this one hitch I keep hitting.

The workaround I usually use when that happens is to pick a existing torrent that you added from a magnet link, then have the other end add the same magnet link, which downloads the magnet-linked file and then (IIUC) finds your source computer via PEX. YMMV; it's worked something like four times out of four for me, but it's a bit cargo-cult.

If your client/libtorrent hates you enough, it won't work with local peers regardless of settings, and two instances of the same version number of the same software will fail to communicate with each other despite the embedded tracker being accessible from the browser.

I wanted to about 2tb of data, mostly torrents, over a wlan from my NAS, and kept getting dropped packets. Eventually I gave up on smb and ftp, and set up opentracker (a simple download and build, with iirc two config options) on my windows desktop under WSL, and swapped the tracker to a local address; after this, it worked perfectly.

Many, many years ago I used to build distributed content delivery infrastructure for K-12 education systems, state and national.

I remember one customer (a state department of education) in particular had a server at each school with reasonable private bandwidth but unreliable routing and dismal internet connectivity, so we used the BitTorrent protocol for eventually-consistent asset distribution between their sites.

See also: using NNTP as your pub/sub message bus.

Can’t you just scp it at that point?

Hypothesizing - that would be more prone to network failure, torrents are very robust against either peer temporarily losing an internet connection.

Iirc SCP supports resuming transfers. Granted torrent architecture is very robust, but I’ve never had a problem with the way scp resumes work.

To resume, someone would have to notice the failure and start it again. If this happens every few minutes, it's effectively impossible. Even once an hour means their overnight transfer is impossible with scp.

Always use rsync. It's almost drop in compatible with scp, you could probably alias it for most uses, but it's more robust against failures and has more features.

That’s actually a good point, and it’d be real easy to spread to a third person were it necessary

scp is terrible over links with low bandwidth and/or high ping.

Reply on news.ycombinator.com