Hacker News Reader

Comment by sixothree | Hacker News Reader

Not long after we started WFH I needed to share a pre-configured VM with a coworker. We tried all sorts of stuff and finally just decided to torrent it. Zipped it up tight with a password and private torrented it overnight. Next morning we were up and running.

View on HN

Next time try Magic Wormhole.

Has anyone got WebRTC’s file sharing to work?

You find a website that creates a link between 2 clients, and the file is shared via https (maybe the file is decrypted at the server and encrypted again using your public key). Sounds easy if both clients don’t have a public IP (to get SCP to work, at least one client needs a public IP) and every browser now has WebRTC.

Yes see https://github.com/kern/filepizza

Resilio sync is delivered from BitTorrent and it works great

Does Syncthing work over the internet, or would you still need to set up a direct line with your colleague?

Netcat...thats what netcat is for....

How do you do that?

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

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.

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

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

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.

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.

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

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.

Reply on news.ycombinator.com