 |
Forums |
Admin  Start New Thread
By: Tom Copeland
 RE: Tracker progress [ reply ]
2004-09-07 16:20
|
> will rubyforge support Seeder(the upload peer)
> and Tracker ?!!
Exactly! I'm running the Python bttracker on bt.rubyforge.org now; I ran the headless download for a bit until I was able to seed them from my home DSL line.
If we can run a Ruby tracker instead, that'd be cool.
> It's cool if the hosting service could
> generate metainfo and seed the files.
Right on. Maybe for any file over a certain size threshhold...
> there are single port seeder
Cool, it would be a good start, at least...
Yours,
Tom
|
By: Ikkei
RE: Tracker progress [ reply ]
2004-09-04 17:45
|
Hi tom,
thx, I had problem that was I input wrong loging name ...now its solved and I import Net::BitTorrent to cvs
Wow, will rubyforge support Seeder(the upload peer) and Tracker ?!!
It's cool if the hosting service could generate metainfo and seed the files.
I had read in BitTorrent FAQ, there are single port seeder. Azreus, Bitcomet does not open many port for upload even it is a lot files.
|
By: Ikkei
RE: Tracker progress [ reply ]
2004-09-03 06:13
|
>> pstore is good choice
> Cool, yup, sounds like it. Thanks for the info. I haven't used pstore before, but it sounds good.
I shoulded write the demerit also for fair comparison.
If use pstore(or even bencode) The CGI read all data to memory per requests. and encode/decode at all load/save time.
This may lose performance when the store file became too big.
To improve that to scarable,
use random access file or dbm or RDB.
and make peer list table which indexed by infohash.
$info_id = SELECT id FROM info_table where infohash = $infohash LIMIT 1
SELECT ip,port FROM peer_table where info_id = $info_id LIMIT $max_give
choose pstore and set limit is also one of solution.
This part is depend on how do you implement the application, its not core Tracker's logic.
Even if you choose which way.
How about make the abstract interface for a store dstat class ?
>> Do you use WEBrick framework ?
> Hm, I have not used it yet... I was just using good old CGI. Perhaps Webrick would be a better choice?
Maybe yes. I also have not used, Now I am trying to use it.
Next, I will write thise TODO for tracker:
- nat_check(ip, port, infohash, peerid) => bool
check peers open the upload port.
It is create tcp socket and trying to connect to peer
and exchange handshake messages.
If tracker work as daemon, those request sessions
can share the scheduler thread for handle sockets.
- pack_ip(ip, port) => String
If request have compact param,
the responce's 'peers' field has binary string that list of ip address and port.
else
peers is just bencoded list of hashes
|
By: Tom Copeland
RE: Tracker progress [ reply ]
2004-09-01 18:20
|
> bencode for store the recent
> downloader information file.
Does it? Ah, OK. Cool.
> I think I did not misunderstand ?
No problem, it was my mistake - I thought we were talking about .torrent files, not dstate.
> pstore is good choice
Cool, yup, sounds like it. Thanks for the info. I haven't used pstore before, but it sounds good.
> Do you use WEBrick framework ?
Hm, I have not used it yet... I was just using good old CGI. Perhaps Webrick would be a better choice?
Yours,
Tom
|
By: Ikkei
RE: Tracker progress [ reply ]
2004-09-01 17:16
|
Hi Tom.
An official bittorrent tracker use bencode for store the recent downloader information file.
and also response data format. not only metainfo file.
I mention the portability was about
the official bittorrent tracker's "dfile"
I think I did not misunderstand ?
If you make the tracker as CGI,
pstore is good choice at thise points:
- Marshal module(which used in psore) is written with C. (generally, we can expect its fast)
- pstore is in stanard library.
- pstore support transaction. (CGI program needs it)
By the way, Do you use WEBrick framework ?
|
By: Tom Copeland
RE: Tracker progress [ reply ]
2004-09-01 14:46
|
Hi Ikkei -
Oh, sorry, I should have been more clear. I agree that bencode is best way to store .torrent files - that's the standard.
What I was wondering about was how the tracker should store the peer information, statistics, and so on. You know, when the client posts in the information using the HTTP GET and the tracker replies with a list of peers.
Yours,
Tom
|
By: Ikkei
RE: Tracker progress [ reply ]
2004-09-01 09:02
|
> What's the best way to store the torrent info in Ruby? pstore, maybe?
Although, what about the best. (speed? maintenance?)
Myabe pstore is ok. at the first time, working is an important. If there are someone who wants to use another store algorythm, they can extend on that time.
I leave my ideas here:
(portability)
The official bittorrent tracker is using bencode.
and No need to load other modules.
(extendability)
pstore, xpstore, Marshal, yaml, bencode etc.
If wrap those by Builder pattern or Strategy pattern,
This approach allows user to switch the store algorythm. (e.g. implement bencode extension with C may be faster)
|
By: Tom Copeland
Tracker progress [ reply ]
2004-08-30 16:06
|
Seems like some things are more important than others for getting a working tracker:
1) Get req/resp working for communicating peer list
2) Get /scrape URL working
3) Stats
What's the best way to store the torrent info in Ruby? pstore, maybe?
Tom
|
|
|
