transmission will only send a torrent once to a client

Ask for help and report issues not specific to either the Mac OS X or GTK+ versions of Transmission
Post Reply
erikj
Posts: 4
Joined: Wed Nov 10, 2021 11:21 pm

transmission will only send a torrent once to a client

Post by erikj »

Dear team - thank you so much for the transmission BT tool.

We are using BT as one of the methods to provision compute nodes with operating system images in a cluster manager.
The clients are using aria2c (but we tested with other clients, more on that later).
We are trying to replace the very old and aging BitTorrent original tracker and seeder content with more modern tooling. We have opentracker-ipv4 for the tracker running.

We prototyped using transmission to replace the BitTorrent seeder we had in our head node and all was well.

However, we later found that we could only ever send the torrent once (between transmission-daemon restarts). For our use case, a compute node may boot many times -- and needs its OS image -- and the head node may be running the seeder for months without rebooting.

In the transmission-remote -t all -pi output, we can see the peer is stuck in 'uI' -- meaning "We will upload if the client asks" but the upload never happens.

I enabled debugging via the environment variables and looked at a first transfer (works) vs a 2nd transfer (never transfers) and I saw
references to BT_FEXT_HAVE_ALL being sent by the client. I looked in the transmission code and found this does a series of things to the
peer. I'm not an expert by any means but I'm guessing if transmission-daemon knows that a client got the whole thing, it never sends it
again. We would like to have an option to allow it to send it again.

This is NOT a patch for inclusion but a patch I made to debug the situation. If I make this change, it will resolve the issue and allow compute nodes to request their image over BT as many times as we need.

Code: Select all

diff -Narup libtransmission/peer-msgs.c~ libtransmission/peer-msgs.c
--- libtransmission/peer-msgs.c~	2020-05-22 06:04:23.390804854 -0500
+++ libtransmission/peer-msgs.c	2021-11-10 17:01:36.722706572 -0600
@@ -1695,6 +1695,8 @@ static int readBtMessage(tr_peerMsgs* ms
 
     case BT_FEXT_HAVE_ALL:
         dbgmsg(msgs, "Got a BT_FEXT_HAVE_ALL");
+        dbgmsg(msgs, "______________erikj______________ ignoring BT_FEXT_HAVE_ALL");
+	break;
 
         if (fext)
         {
Is there something I'm missing that would allow me to enable such a function? If not, may I request that we add a feature? My guess is
I'm just doing something wrong and could use a hand.

Thank you all !!!
erikj
Posts: 4
Joined: Wed Nov 10, 2021 11:21 pm

Re: transmission will only send a torrent once to a client

Post by erikj »

It looks like another option would be to modify the client to not support the 'fast extension' where this HAVE_ALL bitfield is available.

However, this normally seems to be negotiated rather than toggled with a flag.
erikj
Posts: 4
Joined: Wed Nov 10, 2021 11:21 pm

Re: transmission will only send a torrent once to a client

Post by erikj »

To make forward progress, I added some code to the aria2 client where, with a CLI flag, it will never send HAVE_ALL. This seemed easier than disabling the fast extension entirely. This will get me going for now. The client side was easier for us to modify because we support several distros and don't want to build transmission in all its different ways for different distros. We already build aria2 so it was easier to add a patch. I'm still open to any suggestions or if someone thinks I missed something, I'd love to hear about it. Thank you!
erikj
Posts: 4
Joined: Wed Nov 10, 2021 11:21 pm

Re: transmission will only send a torrent once to a client

Post by erikj »

In case an Internet search ends up here, for our unique use case, it seems that using aria2c in daemon mode works better for this "transfer an OS image" case as it always seeds. Even with my research on HAVE_ALL above and avoiding that, we found we had to restart transmission-daemon at times to get seeds going. We're open to trying transmission again if someone has a suggestion or question. We're happy to try new things. Thank you.
Post Reply