4 ms·

How do you do that?

Arnavion 6y ago
Use your client to create a .torrent. Send the .torrent over. Other party adds your IP as a seed. No trackers or DHT required.
- inopinatus 6y ago
  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.
- toxik 6y ago
  Can’t you just scp it at that point?
  - gpm 6y ago
    Hypothesizing - that would be more prone to network failure, torrents are very robust against either peer temporarily losing an internet connection.
    - toxik 6y ago
      That’s actually a good point, and it’d be real easy to spread to a third person were it necessary
    - Bnshsysjab 6y ago
      Iirc SCP supports resuming transfers. Granted torrent architecture is very robust, but I’ve never had a problem with the way scp resumes work.
      - xorcist 6y ago
        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.
      - wccrawford 6y ago
        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.
  - hatsunearu 6y ago
    scp is terrible over links with low bandwidth and/or high ping.
  - deleted 6y ago
    [deleted]
- StavrosK 6y ago
  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.
  - efreak 6y ago
    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.
  - a1369209993 6y ago
    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.

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.

inopinatus 6y ago
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.
toxik 6y ago
Can’t you just scp it at that point?
- gpm 6y ago
  Hypothesizing - that would be more prone to network failure, torrents are very robust against either peer temporarily losing an internet connection.
  - toxik 6y ago
    That’s actually a good point, and it’d be real easy to spread to a third person were it necessary
  - Bnshsysjab 6y ago
    Iirc SCP supports resuming transfers. Granted torrent architecture is very robust, but I’ve never had a problem with the way scp resumes work.
    - xorcist 6y ago
      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.
    - wccrawford 6y ago
      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.
- hatsunearu 6y ago
  scp is terrible over links with low bandwidth and/or high ping.
- deleted 6y ago
  [deleted]
StavrosK 6y ago
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.
- efreak 6y ago
  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.
- a1369209993 6y ago
  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.