Jump to content

UDP:// to HTTP://


NiteShdw

Recommended Posts

While we wait on UDP support, would it be possible for μTorrent to simply detect announce urls that begin with "udp://" and change it to "http://" and attempt to connect to the tracker?

There are only 2 tracker packages that I know that support UDP (XBTT and BitCometTracker), and BOTH support both HTTP and UDP announces on the same URL. In other words, udp://tracker.com:2710/announce and http://tracker.com:2710/announce both connect to the same tracker.

The only case that I can think of the the "http://" would NOT work while the "udp://" would work is if the tracker deliberatly blocked TCP traffic on that port.

In other words, by attempting to connect to "udp://" urls via HTTP, the best case is that it would work and you would get more peers. The worst case is that it wouldn't work, but since the UDP announce URL wouldn't work anyway, there wouldn't be any harm done.

This, of course, could be a temporary solution until UDP announce is supported.

Link to comment
Share on other sites

Well it would need to remember on which torrents it changed the URL. If it didn't work and UDP support was built-in then it would never be able to connect to that tracker. A better feature would not to change the actual URL permanently, but just temporaily to try to connect, then if that fails (for e.g. after x attempts) it should stop the torrent and a warning should be placed in the General tab stating something like 'UDP workaround failed - cant connect to tracker'

I think this feature may be usefull if it is implemented correctly.

Link to comment
Share on other sites

Rare? UDP is newer than the standard HTTP, and much more bandwidth efficient.

Anyway, my point was that trackers that do support UDP also support HTTP, so uTorrent can detect UDP urls and simply try to connect using HTTP instead. THUS, the need for UDP support in uTorrent wouldn't be so urgent.

Plus, my personal tracker uses UDP as the default URL, so I end up editing a lot of torrents by hand (which is what I do now).

Link to comment
Share on other sites

Not really MUCH more, simply no overhead. But there goes reliability aswell, which is very much needed for file transfers rather then speed\efficiency in UDP.

Not ALL UDP trackers support HTTP fallbacks, Some do.

>> Plus, my personal tracker uses UDP as the default URL, so I end up editing a lot of torrents by hand (which is what I do now).

Too bad, you're using a non standard tracking method. Should uTorrent conform to yours ?

Link to comment
Share on other sites

Demonoid, one of the biggest torrent sites, uses UDP. Mongo56 uses UDP. As do plenty of others.

Not ALL UDP trackers support HTTP fallbacks, Some do.

Can you name me one that doesn't? I already talked about the only 2 software packages that support UDP, both of which do both HTTP and UDP.

Plus, I'm not insisting that uTorrent implement UDP support, all I'm asking is that uTorrent try to connect to trackers with UDP:// urls by using HTTP.

Link to comment
Share on other sites

UDP isn't a standard because the protocol itself wasn't well thought out.

There's no mechanism (at least no visible one) for future support of IPv6 in UDP.

There's no mechanism for index sites to scrape an entire tracker via UDP.

There's no mechanism (at least no visible one) for the tracker to set announce intervals (which could lead to pretty hefty hammering)

There's no visible mechanism for trackers to enforce client restrictions (requiring specific client versions, etc)

There's no visible mechanism for trackers to send warning messages (such as bad port selection or being unreachable)

Link to comment
Share on other sites

You named internal trackers (XBT, BitComet). I hardly see tracker admins use THAT as a tracker solution rather then something like TBSource or any other stand-alone solution outside of a client.

Explain to me then, How come UDP isnt even a standard way for tracking ?

What? XBT Tracker is a stand-alone tracker. XBT Client is the client. BitCometTracker is also a standalone tracker, completely separate from the client.

XBT Tracker

BitCometTracker

There's no mechanism (at least no visible one) for future support of IPv6 in UDP.

There's no mechanism for index sites to scrape an entire tracker via UDP.

There's no mechanism (at least no visible one) for the tracker to set announce intervals (which could lead to pretty hefty hammering)

There's no visible mechanism for trackers to enforce client restrictions (requiring specific client versions, etc)

There's no visible mechanism for trackers to send warning messages (such as bad port selection or being unreachable)

1. That could be true, though IPv6 isn't 'standard' at this point in time

2. Somewhat false: "Up to about 74 torrents can be scraped at once. A full scrape can't be done with this protocol."

3. False. The announce ouput contains a 32-bit integer for "interval"

4. True. But blocking peers from accessing a tracker is against BitTorrent protocol as well.

5. False. UDP supports error output including a text message describing the error.

You can find all the answers here: UDP Tracker Protocol

Link to comment
Share on other sites

2. Somewhat false: "Up to about 74 torrents can be scraped at once. A full scrape can't be done with this protocol."

Even though my #2 explicitly said

There's no mechanism for index sites to scrape an entire tracker via UDP.

ENTIRE TRACKER.

and

5. False. UDP supports error output including a text message describing the error.

This is wrong because I specified warning messages, not failure messages. Failure messages are for rejection and are fatal. Warning messages are nonfatal and are for informational messages.

There's no visible mechanism for trackers to send warning messages (such as bad port selection or being unreachable)
announce output

Offset Size Name Value

0 32-bit integer action 1

4 32-bit integer transaction_id

8 32-bit integer interval

12 32-bit integer leechers

16 32-bit integer seeders

20 + 6 * n 32-bit integer IP address

24 + 6 * n 16-bit integer TCP port

20 + 6 * N

As for #3, I stand corrected.

My post is in here because of chaosblade's:

Explain to me then, How come UDP isnt even a standard way for tracking ?
Link to comment
Share on other sites

My post is in here because of chaosblade's:
Explain to me then, How come UDP isnt even a standard way for tracking ?

So because chaosblade's post was off topic, yours is too? I would just ignore off topic posts as replying to them would digress from the topic.

BTW, this feature request (if you read the original post) wasn't asking for UDP support! It was only asking for a feature to try to contact trackers that have a UDP:// announce URL via HTTP. UDP support is a completely different topic.

Back on topic: As I understand it this requested feature would only be needed on rare occasions and only untill UDP support, which is planned, is implemented. It's not a bad idea, I just doubt if it's worth the energy from the developers to implement this temporary feature.

Link to comment
Share on other sites

Well, that's not a definite indication. There are features added whose threads the devs never bothered to respond to.

I'm not sure how UDP trackers work, but here's my thoughts. If UDP trackers can go down without taking the HTTP portion of the tracker down also, then this might be a useful fallback feature. Otherwise, if this isn't how UDP trackers work, then I'm with DrS, and say that it would be a waste of the developers' time to implement this.

Link to comment
Share on other sites

Why wait for a new version to do this when we could just wait for a new version that supports UDP?

Because implementing this idea would take only a few extra lines of code (i.e. easy) while implementing UDP would take considerably more time and effort. Of course, if UDP is already almost finished, then this is pointless. However, if they haven't even started, then this would be great.

Link to comment
Share on other sites

Well, that's not a definite indication. There are features added whose threads the devs never bothered to respond to.

I'm not sure how UDP trackers work, but here's my thoughts. If UDP trackers can go down without taking the HTTP portion of the tracker down also, then this might be a useful fallback feature. Otherwise, if this isn't how UDP trackers work, then I'm with DrS, and say that it would be a waste of the developers' time to implement this.

The only tracker programs that support the UDP tracker protocol also support the standard HTTP protocol, and the way those trackers support both, one system is a failover for the other. Peerlists are shared tracker-side between HTTP and UDP (In much the same way that trackers with multiple listen ports share peerdata among the ports. It's all one program instance with one set of peer info).

Link to comment
Share on other sites

  • 2 weeks later...
Rare? UDP is newer than the standard HTTP, and much more bandwidth efficient.

Uhh, just so you understand, HTTP and UDP do not do the same thing. UDP is a Layer 4 protocol while HTTP is a layer 7 protocol (iirc). The UDP used in trackers is an unofficial protocol that runs OVER UDP, I think..

Link to comment
Share on other sites

The UDP used in trackers is an unofficial protocol that runs OVER UDP, I think..

The UDP announce protocol, although it may be bandwidth efficient, is NOT well thought out.

If you look up, you see the points that I have brought up as problems with the protocol. Of the 5 points I originally brought up, 4 of them still stand.

Link to comment
Share on other sites

  • 2 months later...
UDP isn't a standard because the protocol itself wasn't well thought out.

There's no mechanism (at least no visible one) for future support of IPv6 in UDP.

There's no mechanism for index sites to scrape an entire tracker via UDP.

There's no mechanism (at least no visible one) for the tracker to set announce intervals (which could lead to pretty hefty hammering)

There's no visible mechanism for trackers to enforce client restrictions (requiring specific client versions, etc)

There's no visible mechanism for trackers to send warning messages (such as bad port selection or being unreachable)

1. > 99% of the users currently using BT do not use IPv6. Also, the fact you don't see it doesn't mean it's not there.

2. Why would one be needed? You can simply scrape it via HTTP.

3. False.

4. No reliable one exists for HTTP either.

5. True, but why don't you let the tracker admin decide whether he'd like to run UDP (maybe in addition to HTTP)?

Link to comment
Share on other sites

1> If the mechanism is there, Quote it.

2> Why half-implement a feature in a protocol?

3> I already stood corrected for that earlier. Scroll up.

4> The one for HTTP is more reliable than the one for UDP.

5> What does your question have to do with my concern?

You have also rebuilt part of TCP on top of UDP in the protocol specification. Why bother with that when the data needs to get there with integrety rather than speed?

Link to comment
Share on other sites

1> If the mechanism is there, Quote it.

2> Why half-implement a feature in a protocol?

3> I already stood corrected for that earlier. Scroll up.

4> The one for HTTP is more reliable than the one for UDP.

5> What does your question have to do with my concern?

You have also rebuilt part of TCP on top of UDP in the protocol specification. Why bother with that when the data needs to get there with integrety rather than speed?

1. Extra data can be appended after each fixed size message. By doing this, you can implement any extension you'd like.

2. Because single scrapes are very common and benefit from UDP while normal clients don't do full scrapes and full scrapes don't benefit from UDP.

3. I know.

4. Both have basically 0 reliability. You don't believe in security through obscurity do you?

5. Your concern is that tracker (admin)s can't send warnings. My reply is: why don't you let them decide for themselves whether they want to do that or trade it for UDP?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...