Opened 10 years ago

Closed 5 years ago

#117 closed Enhancement (fixed)

UDP tracker protocol support (BEP #15)

Reported by: jah Owned by: jordan
Priority: Normal Milestone: 2.30
Component: libtransmission Version: 0.6
Severity: Normal Keywords: bep
Cc: jch@…, tiennou7@…

Description

Could be handy.

Here is the specification: http://xbtt.sourceforge.net/udp_tracker_protocol.html

Attachments (8)

announcer_udp.patch (63.4 KB) - added by ijuxda 6 years ago.
Patch to svn/trunk r11758
Test-UDP.torrent (4.3 KB) - added by gunzip 6 years ago.
announcer_udp-v2.patch (70.6 KB) - added by ijuxda 5 years ago.
Patch to svn/trunk r11778
announcer_udp-v3.patch (71.5 KB) - added by ijuxda 5 years ago.
Patch to svn/trunk r11822
announcer_udp-v4.patch (70.0 KB) - added by ijuxda 5 years ago.
Patch to svn/trunk r11842
announcer_udp-v5.patch (70.4 KB) - added by ijuxda 5 years ago.
Patch to svn/trunk r11855
announcer_udp-v6.patch (71.0 KB) - added by ijuxda 5 years ago.
Patch to svn/trunk r11872
announcer_udp-v7.patch (73.5 KB) - added by ijuxda 5 years ago.
Patch to svn/trunk r11889

Download all attachments as: .zip

Change History (92)

comment:1 Changed 9 years ago by aaroncorey

  • Owner changed from somebody to aaroncorey

I'm working on this by creating a evudp analogue to evhttp. Advice welcome.

comment:2 Changed 9 years ago by aaroncorey

  • Milestone changed from Sometime to None Set
  • Priority changed from Normal to Lowest
  • Resolution set to wontfix
  • Severity changed from Normal to Minor
  • Status changed from new to closed

See this discussion as to why the / UDP tracker is a waste of effort .

Since there's so little support or need for this, I'm going to deassign and wontfix.

comment:3 follow-up: Changed 9 years ago by livings124

  • Milestone None Set deleted
  • Priority changed from Lowest to Normal
  • Resolution wontfix deleted
  • Severity changed from Minor to Normal
  • Status changed from closed to reopened

We'll decide what we implement/don't implement.

Also, please don't change priority, etc when closing.

comment:4 Changed 9 years ago by livings124

  • Owner aaroncorey deleted
  • Status changed from reopened to new

comment:5 in reply to: ↑ 3 Changed 9 years ago by aaroncorey

Replying to livings124:

We'll decide what we implement/don't implement.

I apologize for any disturbance. Maybe you should get this sort of imperious attitude coded into Trac so newbies don't trouble your kingdom.

I have patches for UDP support if anyone wants to help me test them.

comment:6 Changed 9 years ago by aaroncorey

That was probably not called for, but I got jumped up and down on about this by three different people. I got really defensive. I'm sorry, but it's just a ticket, I didn't mean to cause a disturbance. Can I stop getting these nasty messages now?

comment:8 Changed 9 years ago by charles

  • Resolution set to wontfix
  • Status changed from new to closed

Since nobody's followed up on this in over two months, and since there doesn't seem to be anyone else asking for UDP tracker support, I'm going to close this ticket until UDP trackers become more common.

comment:9 Changed 9 years ago by Waldorf

  • Component changed from Transmission to libtransmission
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 0.6 to 1.00+

Charles, I'm reopening this because, as far as i've enquired, UDP sockets are fully supported (stated on there project page and in their IRC). Also a very nice IRC member (jab_doa) said he'd love to try to implement it, and post a patch if he has something.

comment:11 Changed 9 years ago by Waldorf

jab_doa gave me an interesting link to the UDP specification as implemented by libtorrent.

comment:12 Changed 9 years ago by charles

  • Version changed from 1.00+ to 0.6

comment:13 Changed 9 years ago by John Clay

  • Milestone set to None Set

comment:14 Changed 8 years ago by dak180

comment:15 Changed 7 years ago by charles

  • Keywords patch-needed added

comment:16 Changed 7 years ago by livings124

This might be of similar interest: http://www.bittorrent.org/beps/bep_0029.html

comment:17 Changed 7 years ago by charles

  • Keywords bep added
  • Summary changed from UDP tracker protocol support to UDP tracker protocol support (BEP #15)

comment:18 Changed 7 years ago by jch

Essential reading before you start:

http://opentracker.blog.h3q.com/2008/01/02/the-udp-situation/

--Juliusz

comment:19 Changed 7 years ago by jch

  • Cc jch@… added

comment:20 Changed 7 years ago by tiennou

  • Cc tiennou7@… added

I'm currently looking at this, trying to merge wereHamster branch to the current trunk.

One idea I just got by looking at the new announcer thingy, is that I think trackers would be happy to see more UDP traffic than HTTP, so it would be preferable to failover from UDP to HTTP (not the other way around). I think it can be done by adding a support_udp thing inside struct tr_host, which would be updated depending on if the tracker support UDP or not. Maybe we could even try a few UDP connects before giving up and using HTTP ?

Another thing, the new annoucer doesn't care about the protocol part of an url : I have a few torrents with announces starting with udp://, and it happily do the createAnnounceURL stuff on them, then pass it to curl. I have no idea if that makes it fail or not.

See lastest commit on http://github.com/tiennou/transmission/tree/udp-tracker for a patch.

comment:22 Changed 7 years ago by tiennou

From looking at those that appears on http://en.wikipedia.org/wiki/Comparison_of_BitTorrent_tracker_software :

  • It seems to me that PHP-based trackers wouldn't be able to support UDP, and none of them actually does.
  • Some in this list aren't even trackers, they're just apps providing trackers stats (and they use HTTP).
  • opentracker and xbtt have UDP support (though xbtt is stated as experimental).
  • cbtt doesn't respond. And I can't found one named "denisx" :(.

comment:23 Changed 6 years ago by charles

  • Resolution set to invalid
  • Status changed from reopened to closed

After reading discussion between tracker and client software authors in #bittorrent I think it's probably best to pass on this ticket. The general consensus seems to be that the current UDP tracker protocol is brittle and needs to be replaced.

comment:24 Changed 6 years ago by charles

  • Resolution invalid deleted
  • Status changed from closed to reopened

Reopening this ticket.

I think the general consensus is still that the current UDP tracker protocol is brittle and needs replacing, but that replacement has not happened yet. In addition, Transmission not having this feature is now causing problems: openbittorrent.com has disabled http announces, apparently permanently, so without UDP announce support, Transmission won't work as well as it could with that tracker.

Use case: linuxmint.com uses openbittorrent.com for its Linux Mint 9 .torrent files.

Last edited 6 years ago by charles (previous) (diff)

comment:25 Changed 6 years ago by charles

tiennou: is this ticket still something that you're interested in? If so, do you want to sync your patch to trunk for consideration in 1.20?

comment:26 Changed 6 years ago by tiennou

I'll take a look, but I don't even remember the state of my patch.

comment:27 Changed 6 years ago by dwpbike

i am interested in transmission supporting udp trackers, namely udp://tracker.publicbt.com:80/announce. att has seen fit to block seeding involving certain trackers; i.e, i see a brief connect, but no seed. i am a conscientious seeder, so why can't i add a udp tracker?

Changed 6 years ago by ijuxda

Patch to svn/trunk r11758

comment:31 Changed 6 years ago by ijuxda

Here's the preliminary patch for UDP tracker support. Announcing and scraping UDP trackers appears to work in my tests, though there are probably still lots of bugs. Testing and feedback encouraged.

The heart of the implementation is in the new file announcer-udp.c. Announcer internals from announcer.c needed by the new code were moved to announcer-common.h. (Possibly in the future the web-specific announcer code could be moved to its own file announcer-web.[ch] as well, but this would require quite a bit more rewriting.)

In order to resolve tracker hostnames without blocking the event thread, the non-blocking resolver from libevent was added to libtransmission. If this does not work out well or is otherwise undesirable an alternative (and perhaps more robust) approach would be to have a separate thread for blocking calls to getaddrinfo.

Other additions:

  • htonll and ntohll for 64bit network byte order conversion.
  • tr_addressUnpackSockaddr converts from sockaddr_storage to tr_address (the reverse of setup_sockaddr).
  • tr_addressUnpack is used for parsing the results of DNS queries.
  • tr_netRecvFrom and tr_netSendTo wrap recvfrom(2) and sendto(2) respectively so that other parts of libtransmission only need to deal with tr_address and a host-byte-order tr_port.
  • tr_isValidTrackerAddress to check bogus DNS responses.
  • TR_GNUC_PACKED attribute for packet structs.

Changed 6 years ago by gunzip

comment:32 Changed 6 years ago by gunzip

ijuxda, i've tried a couple public torrents with your announcer_udp.patch and it's working perfectly .. both torrents had a single udp tracker from openbittorrent.com and peers were picked up quite readily.

also i notice transmission-remote, the webgui, and the utilites now all recognize the udp trackers when before they did not.

as a test i made a small torrent with a single udp tracker, and can seed it for the next day or two if you or anyone with the patch wants to see if they can leech from me. (attachment Test-UDP.torrent).

$ transmission-show Test-UDP.torrent 
Name: Test-UDP
File: Test-UDP.torrent

GENERAL

  Name: Test-UDP
  Hash: 4ece5b02c0e950d0914298f0734db9fc69859cc6
  Created by: Transmission/2.20b2 (11769)
  Created on: Thu Jan 27 05:49:15 2011
  Piece Count: 204
  Piece Size: 32.00 KiB
  Total Size: 6.35 MiB
  Privacy: Private torrent

TRACKERS

  Tier #1
  udp://tracker.openbittorrent.com:80/announce

FILES

  Test-UDP/transmission-2.20b2.tar.bz2 (4.09 MiB)
  Test-UDP/transmission-2.20b2.tar.xz (2.26 MiB)
Last edited 6 years ago by gunzip (previous) (diff)

comment:33 follow-up: Changed 6 years ago by gunzip

one small quirk with the announcer_udp.patch (using netstat command):

tcp   0.0.0.0:10530    21394/transmission-
tcp   0.0.0.0:9091     21394/transmission-
udp   0.0.0.0:37964    21394/transmission-
udp   0.0.0.0:10530    21394/transmission-

in settings.json my listen port range is 10520-10530 (which are forwarded TCP/UDP in my router) but i'm seeing now udp attached to port 37964, which was absent prior to the patch. since that port is blocked for incoming connections would this adversely affect performance?

comment:34 Changed 6 years ago by jordan

This would be very nice to get into 2.20. Of all the big-change tickets, this is one that I'd consider breaking the freeze for.

We're coming up on the freezes for the spring release cycles. In particular, the Fedora and Ubuntu feature freezes are coming up soon. The first one is F15, which is on February 8... so we've got under two weeks until 2.20 comes out with or without UDP announces.

There *is* some wiggle room after that in which we can get bugfixes in, but if we go that route, we still need to be careful about what goes into 2.20. We don't want to turn our mac users into beta testers for the linux users.

ijuxda do you have an opinion how much work this patch needs?

comment:35 follow-up: Changed 6 years ago by jordan

Just at very first glance I have a couple of suggestions. I'll try to do a more substantive review tonight.

  • Are the static _PKT_dummy variables there to tell evbuffer how large it should be? Why not make the req variables structures (not pointers), populate them, and push them through evbuffer_add() instead? Then we wouldn't need static variables.
  • tr_netRecvFrom() appears to be unused.
  • au_state.errstr appears to be unused.
  • au_transaction.errstr appears to be used only as a bool, not a string
  • (superficial) add some wrapper functions (tr_ntohll() and tr_htonll()) so the ifdef code can be moved from utils.h to utils.c, similar to how tr_strlcpy() is done.

comment:36 in reply to: ↑ 33 ; follow-up: Changed 6 years ago by ijuxda

Replying to gunzip:

in settings.json my listen port range is 10520-10530 (which are forwarded TCP/UDP in my router) but i'm seeing now udp attached to port 37964, which was absent prior to the patch. since that port is blocked for incoming connections would this adversely affect performance?

The udp listening port 37964 is probably being used by evdns (the dns resolver in libevent) for receiving dns replies. I say probably because the evdns implementation on my system does not appear to do this. I am quite certain this is not the udp socket used for tracker communication, since I made the code just use the socket already being used for dht, utp, etc. (i.e. port 10530 in your listing).

During testing I noticed that my router will forward incoming udp packets to a non-forwarded port if it sees the initial outgoing udp packet from that port. I assume this is due to some "stateful firewall" feature where it keeps track of the addresses and ports involved. So if your router has a similar feature enabled udp tracker communication should work even if your bittorrent port is not being explicitly forwarded.

I did notice some other oddness from evdns: queries for hostnames with more than 2 dots appear to timeout, even though the host command resolves them without problem. The names also appear to have their case randomly mangled (e.g. tRaCKer.soMEhosT.cOM) for no apparent reason when the dns packets are shown in wireshark.

comment:37 in reply to: ↑ 35 Changed 5 years ago by ijuxda

Replying to jordan:

ijuxda do you have an opinion how much work this patch needs?

My main concern is the evdns related portion, which seems a bit unreliable at the moment. Unfortunately I do not have a good estimate of the time required to fully evaluate and fix the entire patch as it could contain bugs and design issues I am not currently aware of.

Personally I would rather have more time for testing than to rush this code in during the last two weeks of the beta. The feature is nice, but I don't think it's so critical as to be really worth the risk.

Replying to jordan:

Are the static _PKT_dummy variables there to tell evbuffer how large it should be? Why not make the req variables structures (not pointers), populate them, and push them through evbuffer_add() instead? Then we wouldn't need static variables.

Originally I wanted to avoid the extra copy and simply have the buffer allocate the space for the packet and the pointer set to it (so that assignment through the pointer would write directly to the buffer). Unfortunately I could not make evbuffer_reserve_space() + evbuffer_commit_space() do what I wanted (they appear to allocate more than I request, but perhaps I was just not using them correctly).

The benefits of the current approach are:

  • The packet memory is initialized to zero.
  • Writing through the pointer writes directly to the buffer.
  • You can append to the buffer or use the pointer in any order.
  • You do not have to remember to copy the struct data to the buffer after you are done filling it, i.e. everything is set up after the one macro call.

The downside is the static "dummy" variable, though it has its own scope and is thread-safe (since it is only ever read from). Perhaps just renaming it to something more technical sounding and making it const would be acceptable?

tr_netRecvFrom() appears to be unused.

This was included for the eventual cleanup of the other code in tr-udp.c, which does not appear to be quite completely integrated yet with the rest of libtransmission. Admittedly, that belongs in another ticket.

au_state.errstr appears to be unused.
au_transaction.errstr appears to be used only as a bool, not a string

I found keeping the strings around useful during debugging, but I suppose now I have no problem with them being removed/replaced respectively.

(superficial) add some wrapper functions (tr_ntohll() and tr_htonll()) so the ifdef code can be moved from utils.h to utils.c, similar to how tr_strlcpy() is done.

I wanted to avoid the tr_ prefix so that the functions would be exactly analogous to their 32-bit (and smaller) counterparts, as they are on other systems that provide the 64-bit versions. Keeping the definitions in the header also allows the macros to just expand to their argument on systems that do not need to byte swap. This is a rather trivial point and if you still really want to use the wrapper approach I will make the changes.

I'll wait for your review before posting an updated version of the patch.

comment:38 in reply to: ↑ 36 Changed 5 years ago by ijuxda

Replying to ijuxda:

I did notice some other oddness from evdns: [...] The names also appear to have their case randomly mangled (e.g. tRaCKer.soMEhosT.cOM) for no apparent reason when the dns packets are shown in wireshark.

Upon research this turns out to be part of the evdns implementation and is security related (http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00).

comment:39 Changed 5 years ago by gunzip

@ijuxda: just to add i did another test with a single udp-tracker only torrent, but this time i disabled DHT and PEX which i thought to be a more stringent test. the torrent initially scraped 1,595 seeds and 408 leeches, and within 4 minutes i reached my peer-limit of 90 connections:

90 peers connected: Trackers: 23  DHT: 0   LTEP: 0   PEX: 0   Incoming: 67

the peers were solely acquired by the udp tracker. of course on the same udp torrent with DHT and PEX enabled it only takes about 20-30 seconds to reach 90 peers as DHT and PEX were always quite effective in Transmission.

in any event, this is pretty strong evidence that your udp announce patch is performing quite well regardless of any fine tuning you deem is necessary.

Edit: That fact that i saw "Incoming: 67" above validates your point that i'm not being blocked for tracker communication.

Last edited 5 years ago by gunzip (previous) (diff)

comment:40 Changed 5 years ago by jordan

  • Milestone changed from None Set to 2.30

Changed 5 years ago by ijuxda

Patch to svn/trunk r11778

comment:42 Changed 5 years ago by gunzip

@ijuxda: i couldn't get r11778 to build with announcer_udp-v2.patch

$ make
...
./libtransmission.a(tr-udp.o): In function `check_udp_tracker':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/tr-udp.c:122: undefined reference to `tr_announcerHandleUDP'
./libtransmission.a(announcer.o): In function `stopNew':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/announcer.c:150: undefined reference to `au_create_stop'
./libtransmission.a(announcer.o): In function `stopSend':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/announcer.c:185: undefined reference to `au_send_stop'
./libtransmission.a(announcer.o): In function `tr_announcerInit':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/announcer.c:251: undefined reference to `au_context_new'
./libtransmission.a(announcer.o): In function `tr_announcerClose':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/announcer.c:275: undefined reference to `au_context_free'
./libtransmission.a(announcer.o): In function `parseAnnounceResponse':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/announcer.c:1094: undefined reference to `au_parse_announce'
./libtransmission.a(announcer.o): In function `tierAnnounce':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/announcer.c:1495: undefined reference to `au_send_announce'
./libtransmission.a(announcer.o): In function `parseScrapeResponse':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/announcer.c:1519: undefined reference to `au_parse_scrape'
./libtransmission.a(announcer.o): In function `tierScrape':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/announcer.c:1678: undefined reference to `au_send_scrape'
./libtransmission.a(announcer.o): In function `onUpkeepTimer':
/root/TRANSMISSION/transmission-2.20b2/libtransmission/announcer.c:1842: undefined reference to `au_context_periodic'
collect2: ld returned 1 exit status
make[1]: *** [blocklist-test] Error 1
make[1]: Leaving directory `/root/TRANSMISSION/transmission-2.20b2/libtransmission'
make: *** [all-recursive] Error 1

sans the patch it builds successfully.

comment:43 Changed 5 years ago by ijuxda

That's a bit strange, since it looks as though the object file announcer-udp.o is not being linked in, but as you can see from the patch the source file announcer-udp.c is included in Makefile.am. Perhaps you just need to run ./autogen.sh? (Though I would have thought that make would automatically rerun automake when it sees that Makefile.am has been modified.)

I tested compilation on a pristine checkout of r11784 and there were no linker errors.

Also a suggestion: if you are compiling in /root/TRANSMISSION/ I assume you are compiling as the root user. This should not be necessary, and could possibly be dangerous if the build files and source code are not 100% vetted. Whenever possible you should not be using the root account. Compile under your user account and use sudo if needed afterwards. Of course I assume you know what you are doing, so disregard the previous if you are sure that it does not apply to your setup or system.

comment:44 Changed 5 years ago by ijuxda

Charles can you please have a look at tierCopyAttributes(), trackerItemCopyAttributes() and tr_announcerResetTorrent()? They seem a bit suspicious to me. Are they working as you originally intended?

comment:45 in reply to: ↑ 41 ; follow-up: Changed 5 years ago by gunzip

@ijuxda: I was having major headaches with ./autogen.sh but it's sorted now (after a hack) and i have a successful build. I've since tried 2 torrents with a single udp tracker (DHT/PEX disabled), and performance was very good and comparable to what i reported on your first patch:

90 peers connected: Trackers: 28  DHT: 0   LTEP: 0   PEX: 0   Incoming: 62

one difference from the first patch is the extra udp port is gone, i assume from your dropping evdns? anyway netstat looks like so:

tcp   0.0.0.0:10530    19247/transmission-
tcp   0.0.0.0:9091     19247/transmission-
udp   0.0.0.0:10530    19247/transmission-

the first patch had another quirk i discovered later, that is, there was a rather noticeable time lag when stopping the dameon .. even with no loaded torrents it took around 5-10 seconds to exit. This is not occuring with this newest version.

transmission-daemon 2.20b2 (11784) with announcer_udp-v2.patch

comment:46 in reply to: ↑ 45 Changed 5 years ago by ijuxda

Replying to gunzip:

one difference from the first patch is the extra udp port is gone, i assume from your dropping evdns?

Yes. Besides the issue you mention, there were certain hostnames that for some reason it could never resolve on my system. On the other hand getaddrinfo resolved everything satisfactorily and the threaded implementation took less time to create and test than tracking down the source of the problem in evdns (or my use of it).

the first patch had another quirk i discovered later, that is, there was a rather noticeable time lag when stopping the dameon .. even with no loaded torrents it took around 5-10 seconds to exit. This is not occuring with this newest version.

There could still be bugs relating to the sending of "stop messages" when removing torrents or exiting from the program. Although I do not know of any private udp trackers that keep track of upload statistics, it would be good to test that no information is being lost in this case too. Of course if nobody can find any such trackers I suppose just watching packets with wireshark will have to do.

Changed 5 years ago by ijuxda

Patch to svn/trunk r11822

comment:47 Changed 5 years ago by gunzip

@ijuxda: your udp patch is working out very well. however, with TR 2.20 just out there were major changes in libtransmission/announcer.c and the patch is broken. if you have time to update it i assume jordan can commit this to trunk.

Changed 5 years ago by ijuxda

Patch to svn/trunk r11842

comment:48 Changed 5 years ago by gunzip

thanks ijuxda. i now have announcer_udp-v4.patch and your piece_temp.7.patch both working in r11852.

comment:49 follow-ups: Changed 5 years ago by x190

Unfortunately will not build in xcode.proj and r11852.

r11852/libtransmission/utils.h:16:10: fatal error: 'endian.h' file not found (58 errors)


Can this be fixed?

comment:50 in reply to: ↑ 49 Changed 5 years ago by x190

Replying to x190:

Unfortunately will not build in xcode.proj and r11852.

r11852/libtransmission/utils.h:16:10: fatal error: 'endian.h' file not found (58 errors)


Can this be fixed?

Used full path for endian.h but now I'm getting the following 10 errors.

Undefined symbols:
  "_au_context_periodic", referenced from:
      _onUpkeepTimer in libtransmission.a(announcer.o)
  "_au_send_announce", referenced from:
      _tierAnnounce in libtransmission.a(announcer.o)
  "_au_context_free", referenced from:
      _tr_announcerClose in libtransmission.a(announcer.o)
  "_au_send_stop", referenced from:
      _stopSend in libtransmission.a(announcer.o)
  "_au_parse_scrape", referenced from:
      _parseScrapeResponse in libtransmission.a(announcer.o)
  "_tr_announcerHandleUDP", referenced from:
      _check_udp_tracker in libtransmission.a(tr-udp.o)
  "_au_send_scrape", referenced from:
      _tierScrape in libtransmission.a(announcer.o)
  "_au_context_new", referenced from:
      _tr_announcerInit in libtransmission.a(announcer.o)
  "_au_parse_announce", referenced from:
      _parseAnnounceResponse in libtransmission.a(announcer.o)
  "_au_create_stop", referenced from:
      _stopNew in libtransmission.a(announcer.o)
ld: symbol(s) not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Changed 5 years ago by ijuxda

Patch to svn/trunk r11855

comment:51 in reply to: ↑ 49 ; follow-up: Changed 5 years ago by ijuxda

Replying to x190:

r11852/libtransmission/utils.h:16:10: fatal error: 'endian.h' file not found (58 errors)

I removed that header and added endianness detection to configure.ac. There are two issues though with the new approach:

  1. It does not appear that the AC_C_BIGENDIAN macro is suitable for systems that are neither big nor little endian. This would be acceptable if transmission is not expected to be portable to such systems.
  2. There might be a problem with macosx universal binaries, due to the fact that autoheader is not being used (source). If universal binaries are required I would appreciate that someone test this case and report if anything goes awry.

Unfortunately will not build in xcode.proj and r11852.

The errors appear to be due to xcode not being aware of the newly added files. You need to figure out (or get livings124 to tell you) how to add the following files to xcode's build system:

libtransmission/announcer-common.h
libtransmission/announcer-udp.c
libtransmission/announcer-udp.h
libtransmission/resolver.c
libtransmission/resolver.h

or possibly just the .c files. The alternative is to build using autogen.sh/configure and make.

comment:52 in reply to: ↑ 51 Changed 5 years ago by x190

Replying to ijuxda:

Replying to x190:

Unfortunately will not build in xcode.proj and r11852.

The errors appear to be due to xcode not being aware of the newly added files. You need to figure out (or get livings124 to tell you) how to add the following files to xcode's build system:

libtransmission/announcer-common.h
libtransmission/announcer-udp.c
libtransmission/announcer-udp.h
libtransmission/resolver.c
libtransmission/resolver.h

or possibly just the .c files. The alternative is to build using autogen.sh/configure and make.

So much stuff to learn! It's enough to make the old gray matter ache sometimes. :)

Can't use autogen.sh as I'm missing a couple of essential items atm, but note that gunzip had the same linking errors using autogen.sh and had to do some unspecified hacking. Comment:42 and 45.

comment:53 Changed 5 years ago by x190

announcer_udp-v5.patch: 60 errors of the 'port me' type (r11870). Thirsty little devil!

comment:54 follow-up: Changed 5 years ago by x190

Success on macosx patched to r11870 (including #532 patch). Reverted to announcer_udp-v4.patch but had to hack the full path to endian.h in utils.h #include <full path to endian.h>. Wonder why it can't find the darn thing--I've only got about 10 of them kicking around!

Connects to and gets peers from obt no problemo. Two issues so far. If it gets no tracker response, it never times out but remains in 'Announce in progress...' for 20 min. now and counting. Your only recourse is to remove the unresponsive tracker. Also, in the Mac Client Inspector, after the tracker is added you cannot see the udp designation.

Below is a list of some compiler warnings you may wish to check in to.

/Users/!/Transmission/libtransmission/announcer-udp.c:1046:17:{1046:13-1047:36}{1047:39-1047:53}: warning: conversion specifies type 'unsigned int' but the argument has type 'unsigned long' [-Wformat]
             _( "Malformed connect response: expecting length "
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1047:20: note: instantiated from:
                "%1$u but got %2$u" ), sizeof( *res ), len );
                 ~~~^                  ~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1046:30:{1046:13-1047:36}{1047:55-1047:58}: warning: conversion specifies type 'unsigned int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
             _( "Malformed connect response: expecting length "
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1047:33: note: instantiated from:
                "%1$u but got %2$u" ), sizeof( *res ), len );
                              ~~~^                     ~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1064:26:{1064:13-1065:45}{1065:48-1065:62}: warning: conversion specifies type 'unsigned int' but the argument has type 'unsigned long' [-Wformat]
             _( "Malformed announce response: expecting length "
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1065:29: note: instantiated from:
                "at least %1$u but got %2$u" ), sizeof( *res ), len );
                          ~~~^                  ~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1064:39:{1064:13-1065:45}{1065:64-1065:67}: warning: conversion specifies type 'unsigned int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
             _( "Malformed announce response: expecting length "
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1065:42: note: instantiated from:
                "at least %1$u but got %2$u" ), sizeof( *res ), len );
                                       ~~~^                     ~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1081:26:{1081:13-1082:45}{1082:48-1082:62}: warning: conversion specifies type 'unsigned int' but the argument has type 'unsigned long' [-Wformat]
             _( "Malformed scrape response: expecting length "
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1082:29: note: instantiated from:
                "at least %1$u but got %2$u" ), sizeof( *res ), len );
                          ~~~^                  ~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1081:39:{1081:13-1082:45}{1082:64-1082:67}: warning: conversion specifies type 'unsigned int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
             _( "Malformed scrape response: expecting length "
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1082:42: note: instantiated from:
                "at least %1$u but got %2$u" ), sizeof( *res ), len );
                                       ~~~^                     ~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1098:30:{1098:13-1099:49}{1099:52-1099:66}: warning: conversion specifies type 'unsigned int' but the argument has type 'unsigned long' [-Wformat]
             _( "Malformed error response: expecting length "
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1099:33: note: instantiated from:
                "greater than %1$u but got %2$u" ), sizeof( *res ), len );
                              ~~~^                  ~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1098:43:{1098:13-1099:49}{1099:68-1099:71}: warning: conversion specifies type 'unsigned int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
             _( "Malformed error response: expecting length "
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/!/Transmission/libtransmission/announcer-udp.c:1099:46: note: instantiated from:
                "greater than %1$u but got %2$u" ), sizeof( *res ), len );
                                           ~~~^                     ~~~
8 warnings generated.

Last edited 5 years ago by x190 (previous) (diff)

Changed 5 years ago by ijuxda

Patch to svn/trunk r11872

comment:55 in reply to: ↑ 54 ; follow-up: Changed 5 years ago by ijuxda

Replying to x190:

Success on macosx patched to r11870 (including #532 patch). Reverted to announcer_udp-v4.patch but had to hack the full path to endian.h in utils.h #include <full path to endian.h>. Wonder why it can't find the darn thing--I've only got about 10 of them kicking around!

In announcer_udp-v6.patch I take a different approach to endianness detection that does not rely on headers or autoconf (besides checking for htonll/ntohll).

Connects to and gets peers from obt no problemo. Two issues so far. If it gets no tracker response, it never times out but remains in 'Announce in progress...' for 20 min. now and counting. Your only recourse is to remove the unresponsive tracker.

My implementation follows the timeout section in bep15 which uses quite a long total timeout time (i.e. over an hour). This could be changed to something less along the lines of what some of the other pages describing the protocol have, or perhaps just the failed connection case could be given up more quickly. It could also be that there are still bugs in the code. I'll test it out some more and perhaps post an improved version.

Incidentally, is there an easy way to cancel/restart announces for non-udp tracker types? If not, this issue might warrant its own ticket (if it does not have one already).

Also, in the Mac Client Inspector, after the tracker is added you cannot see the udp designation.

The gtk client also has this problem. The displaying of different tracker types in the various front-ends should be fixed in a separate ticket/patch after the patch in this ticket has been accepted.

Below is a list of some compiler warnings you may wish to check in to.

These should be fixed now.

comment:56 in reply to: ↑ 55 Changed 5 years ago by x190

Replying to ijuxda:

Replying to x190:

Connects to and gets peers from obt no problemo. Two issues so far. If it gets no tracker response, it never times out but remains in 'Announce in progress...' for 20 min. now and counting. Your only recourse is to remove the unresponsive tracker.

My implementation follows the timeout section in bep15 which uses quite a long total timeout time (i.e. over an hour). This could be changed to something less along the lines of what some of the other pages describing the protocol have, or perhaps just the failed connection case could be given up more quickly. It could also be that there are still bugs in the code. I'll test it out some more and perhaps post an improved version.

I see what you're doing. It just looks strange as HTTP times out at 2 mins and shows the re-announce intervals in the Inspector.

Incidentally, is there an easy way to cancel/restart announces for non-udp tracker types? If not, this issue might warrant its own ticket (if it does not have one already).

No cancel button (just removal of tracker) but you can manually re-announce after about half of wait period has passed.

Also, in the Mac Client Inspector, after the tracker is added you cannot see the udp designation.

The gtk client also has this problem. The displaying of different tracker types in the various front-ends should be fixed in a separate ticket/patch after the patch in this ticket has been accepted.

Okay. Will try to test this new patch in conjunction with #532 and the jit patch you mentioned in the forum.

comment:57 follow-up: Changed 5 years ago by x190

Now testing with announcer_udp-v6.patch +#532. Here's an error to look at. Tracker is udp://tracker.torxxxxbox.com:2710/announce.

2011-02-12 03:34:50 -0700 announcer-udp.c:272 [Error] UDP Announcer: Transaction error: Malformed announce response: expecting length at least 20 but got 8
2011-02-12 03:34:50 -0700 torrent.c:519 [Error] : Tracker warning: "Tracker gave HTTP response code 500 (Internal Server Error)"

Appears to re-announce in an expected manner.

Also, the following error for udp://tracker.zeroxxxxker.com:2710/announce

2011-02-12 03:43:44 -0700 announcer-udp.c:272 [Error] UDP Announcer: Transaction error: DNS lookup for tracker.zeroxxxker.com:2710 returned invalid address: 127.0.0.1
2011-02-12 03:43:45 -0700 announcer.c:1077 [Info] : Tracker gave HTTP response code 500 (Internal Server Error)

Do you know of any other working udp trackers besides obt?

Overall, looks quite good with timeouts and announce intervals being shown. According to pbt's site they are now udp but I get the following error.

2011-02-12 04:06:41 -0700 announcer-udp.c:272 [Error] UDP Announcer: Transaction error: Failed to send UDP packet: No route to host
2011-02-12 04:06:41 -0700 announcer.c:1077 [Info]: Tracker did not respond
Last edited 5 years ago by x190 (previous) (diff)

comment:58 Changed 5 years ago by x190

Update: OBT and PBT both working nicely and getting peers via UDP altho' it initially took PBT 20 mins. to answer the phone but then I guess they are just getting set up on udp.

Last edited 5 years ago by x190 (previous) (diff)

comment:59 follow-up: Changed 5 years ago by x190

ijuxda, I assume you are aware of the pausing issues? There needs to be a shortened time-out if quit is called (not tested re: quit yet, but, on pause can get stuck in "Announce in progress..." for ages). Also, the seed/leech count in the Inspector does not re-set to 0 even for responsive trackers (OBT) even tho' the Message Log shows 'Got 0 peers from tracker' when pausing.

EDIT: Unresponsive udp trackers do not affect the ability to quit the app.

Last edited 5 years ago by x190 (previous) (diff)

Changed 5 years ago by ijuxda

Patch to svn/trunk r11889

comment:60 in reply to: ↑ 57 Changed 5 years ago by ijuxda

I fixed some bugs and improved the logging messages for version 7. Full commit log is here.

Replying to x190:

Transaction error: Malformed announce response: expecting length at least 20 but got 8

This could be bug in the handler code, or just a randomly mangled packet (for some reason). If this occurs every time and always with the same tracker be sure to report it here.

Transaction error: DNS lookup for tracker.zeroxxxker.com:2710 returned invalid address: 127.0.0.1

Some trackers have their DNS hostname set to an invalid address (i.e. 127.0.0.1), presumably to reduce traffic. To confirm that this is not a bug in the DNS resolver code, try looking up the tracker hostname with another utility.

Do you know of any other working udp trackers besides obt?

Most of the time when testing I just substitute the http prefix with udp and add port 80 (if it is not already there) in the tracker lists for my test torrents.

Transaction error: Failed to send UDP packet: No route to host

It is hard to say what caused this, though with the improved logging in the latest version this should be easier to investigate. If it happens every time an attempt is made and with the same tracker this would indicate a bug. Alternatively, your network connection could be down.

ijuxda, I assume you are aware of the pausing issues? There needs to be a shortened time-out if quit is called (not tested re: quit yet, but, on pause can get stuck in "Announce in progress..." for ages). Also, the seed/leech count in the Inspector does not re-set to 0 even for responsive trackers (OBT) even tho' the Message Log shows 'Got 0 peers from tracker' when pausing.

My patch only makes the minimal amount of changes to the existing "announcer" codebase to make udp trackers functional. Whatever issues there are affecting http trackers, their scheduling, refreshing, etc., would likely affect udp trackers in the same way.

As for the special case of shortening the timeout during quit, I think this deserves its own ticket. Consider that if the announce message is so important as to block the termination of the program, why is there a timeout or a "quit now" button in the first place? And if it is not important, why wait when exiting at all? If this is to ensure statistics are updated on the tracker (e.g. for ratio determination), why not simply have users stop all torrents before exiting (and add some feedback to indicate that the torrent has "synchronized" with the tracker)? These users would already be mentally checking themselves not to quit the application prematurely anyway.

comment:61 in reply to: ↑ 59 ; follow-up: Changed 5 years ago by jordan

Replying to ijuxda:

Incidentally, is there an easy way to cancel/restart announces for non-udp tracker types? If not, this issue might warrant its own ticket (if it does not have one already).

I'm not sure I understand the question, but it's important to understand that trackers get very picky about dropped messages and messages that get sent out of order. To preserve the sequencing, each tracker has a list of pending announces. There are lots of special cases where events get folded out of this list... for example if a user presses the start/stop buttons rapidfire, we can drop many of those events. likewise if there's a periodic announce in the queue followed by something more interesting then we can drop the periodic announce. Any new manipulator functions would need to take these things into consideration.

Replying to x190 and ijuxda:

There needs to be a shortened time-out if quit is called (not tested re: quit yet, but, on pause can get stuck in "Announce in progress..." for ages).

I think this deserves its own ticket.

If there's a new timeout bug caused by the UDP patch, that would be on-topic here. But ijuxda is right that the general question of how-long-do-we-wait-on-shutdown doesn't belong in this ticket.

Consider that if the announce message is so important as to block the termination of the program, why is there a timeout or a "quit now" button in the first place?

To handle situations outside of Transmission's control. Sending &event=stopped is generally a Good Thing, but there's no point waiting forever on an unresponsive tracker...

If this is to ensure statistics are updated on the tracker (e.g. for ratio determination), why not simply have users stop all torrents before exiting (and add some feedback to indicate that the torrent has "synchronized" with the tracker)? These users would already be mentally checking themselves not to quit the application prematurely anyway.

Because it would be a usability nightmare...

Replying to x190

Also, the seed/leech count in the Inspector does not re-set to 0 even for responsive trackers (OBT) even tho' the Message Log shows 'Got 0 peers from tracker' when pausing.

x190, I'm not sure zeroing out the counts would be an improvement. Old data is better than no data...

comment:62 in reply to: ↑ 61 ; follow-ups: Changed 5 years ago by x190

Replying to jordan replying to x190 and ijuxda:

There needs to be a shortened time-out if quit is called (not tested re: quit yet, but, on pause can get stuck in "Announce in progress..." for ages).

I think this deserves its own ticket.

If there's a new timeout bug caused by the UDP patch, that would be on-topic here. But ijuxda is right that the general question of how-long-do-we-wait-on-shutdown doesn't belong in this ticket.

I wouldn't consider this a bug. It's more a case of co-ordinating behavior between udp and http trackers. Jordan, I think you now use a 20 second timeout for unresponsive trackers when quitting?

Replying to jordan replying to x190

Also, the seed/leech count in the Inspector does not re-set to 0 even for responsive trackers (OBT) even tho' the Message Log shows 'Got 0 peers from tracker' when pausing.

x190, I'm not sure zeroing out the counts would be an improvement. Old data is better than no data...

Yeah, for some unknown reason at 3 A.M. that's what I thought http trackers did. What I should have focused more on was that because udp is coded to follow http://www.bittorrent.org/beps/bep_0015.html, the tier can be in "Announce in progress..." for up to 68 min. and does not re-set to "Announce not scheduled" if the user hits "Pause All" and the tracker is unresponsive. I'm not saying this causes any problems, only that users will find it a bit strange intially at least.

Last edited 5 years ago by x190 (previous) (diff)

comment:63 in reply to: ↑ 62 Changed 5 years ago by jordan

Replying to x190:

What I should have focused more on was that because udp is coded to follow http://www.bittorrent.org/beps/bep_0015.html, the tier can be in "Announce in progress..." for up to 68 min. and does not re-set to "Announce not scheduled" if the user hits "Pause All" and the tracker is unresponsive. I'm not saying this causes any problems, only that users will find it a bit strange intially at least.

Saying "Announce in progresss..." for 30+ minutes would cause bug reports along the same lines as the current "queued to announce" ticket. Surely there are better visual cues that could be used.

comment:64 Changed 5 years ago by jordan

  • Milestone changed from 2.30 to Sometime

There are still several loose ends here. I'm not comfortable with milestoning this ticket yet.

comment:65 Changed 5 years ago by ijuxda

The existing announcer codebase and many other parts of the program assume that all trackers are web trackers. Updating this code to better coordinate with the new udp tracker functionality would require substantial cleanup and rewriting, and had I chosen to do this the patch would be many times larger. Instead, my approach was to make the announcer-udp interface emulate the code paths used for web trackers. This makes the changes modular, minimal, and allows easy updating in the future if and when the web specific code is abstracted out of announcer.c (as previously suggested).

Case in point, the "Announce in progresss..." for 30+ minutes issue is only an artifact of the temporary "glue" code, and has about the same importance as the issue with front-ends not distinguishing web/udp trackers in their interfaces. Hence as these are not critical bugs, these problems should be addressed in subsequent patches and tickets, rather than in this patch which is already very large.

Replying to jordan:

There are still several loose ends here. I'm not comfortable with milestoning this ticket yet.

What are the other loose ends you are aware of?

comment:66 in reply to: ↑ 62 Changed 5 years ago by ijuxda

Replying to x190:

What I should have focused more on was that because udp is coded to follow http://www.bittorrent.org/beps/bep_0015.html, the tier can be in "Announce in progress..." for up to 68 min. and does not re-set to "Announce not scheduled" if the user hits "Pause All" and the tracker is unresponsive. I'm not saying this causes any problems, only that users will find it a bit strange intially at least.

I will investigate the cause of this and if I find it is due to logic in the new udp announcer code I will post an updated patch.

comment:67 Changed 5 years ago by jordan

r12126:

(trunk libT) #117 "UDP tracker protocol support (BEP #15)" -- refactor announcer.c so that alternate tracker protocols can be supported.

This commit adds a set of package-visible structs and functions to allow delegating announces and scrapes to different protocol handlers. (Examples: struct tr_announce_request, struct tr_announce_response, struct tr_scrape_request, struct tr_scrape_response.) HTTP is the only protocol handler currently implemented; however, this provides a clean API for other protocol handlers, and having this in trunk will help shake out any bugs in this refactoring.

In addition, logging via the TR_DEBUG_FD environment variable is vastly improved in the announcer module now.

Version 0, edited 5 years ago by jordan (next)

comment:68 Changed 5 years ago by jordan

r12129: fix r12127 bug with delegating https announces

r12131: fix r12127 bug with delegating https scrapes

r12133: add multiscrape

comment:69 Changed 5 years ago by jordan

  • Milestone changed from Sometime to 2.30

comment:70 Changed 5 years ago by jordan

r12141: add UDP tracker support

comment:71 Changed 5 years ago by jordan

r12145: better support for adding UDP announce URLs to torrents in the GTK+ client

r12146: get the Mac build working with the new UDP code

r12149: fix crash in tau_send() reported by Waldorf in related ticket #4114

comment:72 Changed 5 years ago by jordan

r12157: better implementation of tr_htonll() and tr_ntohll()

r12158: add attribution for the fallback tr_htonll() and tr_ntohll() implementations

r12159: fix ABR in the UDP tracker code when a request times out

comment:73 Changed 5 years ago by jordan

r12162 libtransmission/announcer-udp.c: (trunk libT) #117 "UDP tracker protocol support (BEP #15)": (1) use the UDP tracker error response's error string (2) better handling of requests that timeout (3) better filtering of non-tracker UDP messages

comment:74 Changed 5 years ago by jordan

r12167 libtransmission/announcer.c: as discussed with Waldorf, massage the tracker lists a bit:

  • remove duplicate URLs caused by implicit vs. explicit port numbers
  • if two announce URLs are duplicates /except/ for their scheme, put them in the same tier.
  • try announce URLs with a "udp" scheme before trying ones with an "http" scheme.

comment:75 Changed 5 years ago by jordan

The latest trunk seems to be working pretty well, and the last four days' worth of comments on this ticket have been like an echo chamber, all of them are me summarizing the svn commits. :)

Unless anyone has any suggestions or bug reports, I think this feature is complete other than minor futzing...

Last edited 5 years ago by jordan (previous) (diff)

comment:76 follow-up: Changed 5 years ago by gunzip

i noticed a couple bugs, or maybe just quirks, with udp..

1) from netstat command, a udp torrent spawns two extra ports that are outside my listen port range. e.g.

tcp   0.0.0.0:9091     16102/transmission-d
tcp   0.0.0.0:10500    16102/transmission-d
udp   0.0.0.0:10500    16102/transmission-d

udp   0.0.0.0:45091    16102/transmission-d
udp   0.0.0.0:49384    16102/transmission-d

those extra ports are some random high numbers and weren't there in 2.22 and previous releases.

2) also, when i issue the --exit command from transmission-remote, there is a delay of about 25 seconds before it actually quits. with 2.22 it exits under 1 second. this may be related to 1).

comment:77 Changed 5 years ago by jordan

Right, this is the same issue you saw 6 weeks or so ago with one of the other patches, since svn trunk is using evdns too. Unless there's a showstopper in evdns I'd rather not reinvent the wheel in libtransmission, so non-showstopper evdns issues should be reported upstream to the libevent developers.

I suspect the shutdown issue is related to the timing of shutting down evdns; I'll look into that tonight.

Thanks for the report!

comment:78 Changed 5 years ago by jordan

r12180: in case the tracker gives an error message in response to a connection response, store the error message in the scrape/announce response structs' errmsg fields.

comment:79 follow-up: Changed 5 years ago by johnea

I'm running r12188 transmission-daemon and transmission-remote.

When I try to add a udp tracker to a running torrent there is an error:

$ transmission-remote -t 9 --tracker-add udp://tracker.openbittorrent.com:80/announce http://localhost:9091/transmission/rpc/ responded: "invalid argument"

If I stop the torrent, remove it from the list, then add the tracker to the file:

$ transmission-edit -a udp://tracker.openbittorrent.com:80/announce ~/torrent/RichardStallman-20080501-Manchester.torrent /home/johnea/torrent/RichardStallman-20080501-Manchester.torrent

Added "udp://tracker.openbittorrent.com:80/announce" to "announce-list" tier 3

Changed 1 files

When I re-add this torrent to the daemon it picks up the new tracker and seems to be using it.

Of course I lost all of the ratios and stats 8-(

It's great to see this feature added after 5 years! Ticket #117, Wow!

Thanks for everyone's patience and persistence.

comment:80 Changed 5 years ago by jordan

r12185: tr_urlParse(): default to port 80 for URLs with a udp scheme and no explicit port.

r12188: #4114 "crash on open r12168 in tau_sendto()" -- fixed.

r12189: (1) fix connection attempt retries after a failed connection attempt. (2) extract method from tau_tracker_upkeep() for clarity: tau_tracker_send_reqs() and tau_tracker_timeout_reqs()

comment:81 in reply to: ↑ 76 ; follow-up: Changed 5 years ago by jordan

Replying to gunzip:

2) also, when i issue the --exit command from transmission-remote, there is a delay of about 25 seconds before it actually quits. with 2.22 it exits under 1 second. this may be related to 1).

This should be working correctly now in the nightlies.

comment:82 in reply to: ↑ 79 Changed 5 years ago by jordan

Replying to johnea:

$ transmission-remote -t 9 --tracker-add udp://tracker.openbittorrent.com:80/announce http://localhost:9091/transmission/rpc/ responded: "invalid argument"

Fixed in r12191. Thanks for reporting this!

comment:83 Changed 5 years ago by jordan

  • Owner set to jordan
  • Status changed from reopened to new

comment:84 Changed 5 years ago by jordan

  • Status changed from new to assigned

comment:85 Changed 5 years ago by jordan

  • Keywords patch-needed removed

comment:86 in reply to: ↑ 81 Changed 5 years ago by gunzip

Replying to jordan:

Replying to gunzip:

2) also, when i issue the --exit command from transmission-remote, there is a delay of about 25 seconds before it actually quits. with 2.22 it exits under 1 second. this may be related to 1).

This should be working correctly now in the nightlies.

yes, just tried with r12207 and the daemon exits in around 1 second -- huge improvement.

comment:87 Changed 5 years ago by gunzip

when using "transmission-show --scrape" option with a udp-tracker torrent, the output returns..

udp://tracker.openbittorrent.com:80/scrape?info ... error: Unsupported protocol

using r12211 in debian linux

comment:88 follow-up: Changed 5 years ago by jordan

gunzip: that's probably not going to be solved in time for 2.30. It's specific to transmission-show, not libtransmission's announces... could you open a new ticket for it?

Thanks for reporting it though...

comment:89 in reply to: ↑ 88 Changed 5 years ago by gunzip

Replying to jordan:

gunzip: that's probably not going to be solved in time for 2.30. It's specific to transmission-show, not libtransmission's announces... could you open a new ticket for it?

OK on that, see #4141

comment:90 Changed 5 years ago by livings124

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.