Truly Open Tracker

[BoundSyco]

A while ago I wanted to write a tracker just for the hell of it, so I did. When I wrote it, I implemented it the way I thought trackers should be implemented, of course, this doesn't mean that anyone else implements them this way. Most trackers, that I know of, classify themselves as either 'Open' or 'Closed' trackers. Open trackers are those which allow anyone to use them without registration. Closed trackers require registration.

Both varieties of trackers (as far as I know) require that the torrent must be registered with the tracker before the tracker will acknowledge it and track peers for it. The reason for this, as I see it, is to have some sembalence of control over how much bandwidth gets used. This also has the nice benifit that a majority of these trackers also supply a very easy way to find everything that it tracks.

However, in my opinion, the tracker shouldn't be responsible for keeping track of the torrent files. Sure, you can have an integrated service, but they should be seperate entities. I also believe that trackers should track anything that a client points at it. There would be no "registered" torrents for the tracker, and no way to actually know what is being tracked. (This doesn't mean that torrents cannot be banned if a torrent is used for sharing data you do not want widely distributed)

I don't really know if this is a good idea or not, but I would like some feedback.

You can test the tracker by pointing any torrent at:

http://www.wetspunk.net/announce.php

You can check the source code and such here:

http://www.wetspunk.net/

Forums:

http://www.wetspunk.net/forums/

[WebReaper]

Nice domain.

[anoxan]

this sounds...really cool. I'm about to go to sleep, but I'm sure this'll attract some attention pretty fast.

also, love the domain, lol

[Ezra]

It says:

Failure BitComet Banned.

I'm using uTorrent 1.6 BETA...

[Stone]

I can confirm that, using µTorrent build 483 I get the same message.

Edit: typo

[Nefarious]

nice backup trackers is what more trackers should be (i still miss mongo)

Failure: BitComet Banned <-- got that too

[BoundSyco]

Whoops. Sorry about that, I had stristr("bc",$peer_id) == false instead of stristr("bc",$peer_id) != false.

Fixed that.

Edit:

I will release 0.4 when I write a real install script, but that wont come until I get around to improving performance, peer selection logic, and announce abuse prevention (and logic). So far I have been doing a good job of keeping the complexity/memory requirements low and I am hoping to be able to add all of these features without going above 100 lines of code in the announce.php script (I am currently at 103). Keeping the number of lines low isn't about bragging rights, but about forcing myself to find and use built in functions and advanced mysql commands which run faster (and require less memory).

[ICleolion]

Well you come to the right place to promote something that is resource friendly

[BoundSyco]

The only problem is with PHP itself. PHP is, by its very nature, going to require more cpu+memory than something written in c/c++. I am also trying to strike a balance with ease of install and ability to run on existing web infastructure that is pre-exisiting, easy to use, and cheap.

[emtec666]

How would this perform in comparison to XBT tracker?

[BoundSyco]

C++ will more than likely outperform php. I don't have any performance data unfortunately (as no one uses the tracker really).

As it stands, I think it should be able to serve 50,000 to 75,000 full user requests per minute on my current shared server. This is only a guess however based upon indvidual requests and such.

Edit:

I was thinking about how to more closely aproximate the speed achieved by compiled languages and decided to implement a multithreaded approach. (In theory this should reduce the apparent reaction time of the tracker, placing delayable processing components (such as abuse detection) in the background.

[emtec666]

I don't have any performance data unfortunately

Well if you need data I can add it as a backup tracker, usually I get a few 100 of peers on an upload (I find it to risky to use as a main tracker since it's still in development)

[silverfire]

@BoundSyco: Would the server that it's on be capable of handling medium-high volume releases? Because if you want, I can help you stress-test the tracker sometime soon. PM//email me if you're interested.

[Ezra]

But still it would be nice if you'd implement a scrape page, that way torrent searchengines like isohunt can find the torrents on your tracker and add it as multi-tracker.

[kai1211]

I know of some tracker that you do not need to register or upload you're torrent to it for it to track it. I am posting this as no disrespect to the poster but I just thought he me be interested.

http://tracker.prq.to/announce

http://tracker.bitebbs.com:6969/announce

http://www.torrent-downloads.to:2710/announce

There are others I just can not remember what they are off the top of my head. Thanks and have a good day.

[silverfire]

@kai1211: Try reading his entire post and not just the first three words. He meant that the tracker would track ANY hash that it got pointed to, not just the ones that the .torrent files got uploaded for.

[BoundSyco]

Sorry for not responding to those of you with questions yet. I recently have had corrective eye surgery. I am not able to use the computer for long periods of time because it will obfuscate my vision as my eyes heal (Not to mention it is hard to focus on anything). In a little while I will be back at it.

[Ultima]

Hm, I'd thought this idea sounded familiar... http://www.whitsoftdev.com/opentracker/

That's another open tracker I came across a while ago, but it's cool that yours is more compact

[BoundSyco]

Bringing back the dead is awesome.

So apparently this single post has me getting in the neighborhood of 7,000 to 25,000 announces a day. I didn't even realize until I noticed my database usage was abnormally high for my normal pitiful usage. Anyways, it illustrated a great number of issues I had with the current setup, so I remedied them in ways I felt were adequate. In fact, I added features, reduced the total lines of code and reduced cpu usage.

Previous setup:

Memory Footprint: ~4.5kB

CPU Time per request: ~0.09

Mysql Connection/Query ratio: 1:3

Current setup:

Memory Footprint: ~4.5kB

CPU Time per request: ~0.03 (Edit: Yesterdays usage spiked again. CPU time per request dropped to 0.009)

Mysql Connection/Query ratio: ~1:250 (Edit: Current ratio is about 1:400)

The current setup is using fastcgi with persistent database connections. The previous setup is neither. I suspect that with the code cleanup I performed, the average request time would have dropped by one fifth to one tenth without the persistent processes or connections.

All of this is performed on shared hosting. Dedicated hosting would be faster still. I have one more speed trick I would like to try, but I do not know if I have access to it yet (my provider is installing php optimizers on all of their servers, it just takes time). If someone wants to test it on a larger release I would like to see what happens. (Use other trackers obviously. I would just like to see what happens when it gets pounded. I suspect that performance per request will actually increase (fastcgi / persistent connections work better the more requests there are).

[thenutthouse]

I love bringing old topics back to life and am very interested in trying out your tracker. Unfortunately it appears that it, along with your site, are down at the moment.

I am an admin at another forum and am looking at installing a new tracker on it and would love to help you out in testing it if you have gotton further along on it and have it stable yet.

email me when you have it back up