June 6, 2010 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >
June 6, 2010 NOTICE: This channel is no longer actively logged.
[00:53:29] *** Switeck has joined #bittorrent[00:55:52] *** rdjong has joined #bittorrent[01:02:12] *** rdjong has quit IRC[03:16:17] *** init0 has quit IRC[03:18:10] *** init0 has joined #bittorrent[03:27:19] *** goussx has quit IRC[03:34:33] *** ProperNoun has joined #bittorrent[04:03:24] *** The_8472 has quit IRC[04:09:20] *** The_8472 has joined #bittorrent[04:41:22] *** chelz has quit IRC[04:52:07] *** jonasl has quit IRC[04:55:02] *** jonasl has joined #bittorrent[05:47:21] <Arc> is the bencoded 20-byte peer_id urlescaped or not?[05:47:28] <Arc> that is unclear in the docs[05:47:56] <TheSHAD0W> Yes.[05:48:24] <Arc> shit. im going to have to write a new function for that then[05:48:36] <TheSHAD0W> Nothing available in the stock libraries?[05:48:46] <Arc> glib's urlescape doesn't support %00[05:48:53] <TheSHAD0W> Some clients just escape EVERYTHING.[05:49:01] <Arc> that seems rather inefficient[05:49:07] <TheSHAD0W> It is.[05:49:15] <TheSHAD0W> But it's simple.[05:49:22] <Arc> *twitch*[05:49:26] <TheSHAD0W> And 2/3 of the chars have to be escaped anyway...[05:49:46] <Arc> well im almost done with a new tracker[05:49:47] <TheSHAD0W> Good for a temporary fix, you can work on a real escape function later.[05:50:00] <TheSHAD0W> Um.[05:50:11] <TheSHAD0W> If you're working on a tracker... Why do you need an escape function?[05:50:16] <TheSHAD0W> Or do you need a decode function?[05:50:22] <Arc> i already have a decode function[05:50:32] <Arc> when the tracker returns the peer_id in the bencoded block[05:50:50] <TheSHAD0W> ...[05:50:54] <Arc> in the peers dictionary, peer_id[05:50:58] <TheSHAD0W> No, the bencoded data isn't escaped.[05:51:02] <Arc> peer id: peer's self-selected ID, as described above for the tracker request (string)[05:51:04] <TheSHAD0W> Only the url passed to the tracker.[05:51:33] <Arc> ok so its always "d7:peer id20:%s" where s is 20 bytes?[05:51:37] <TheSHAD0W> Yes.[05:51:44] <TheSHAD0W> Although...[05:51:44] <Arc> MUCH easier. thanks :-)[05:51:53] *** Gottaname2 has joined #bittorrent[05:51:59] <TheSHAD0W> No modern clients should need that data.[05:52:10] <Arc> yea but im very ocd about standards[05:52:21] <TheSHAD0W> If you don't get no_peer_id or compact flags, you might as well send an error message saying to upgrade the client software.[05:52:41] <Arc> yea?[05:52:45] <TheSHAD0W> Yup.[05:53:26] <Arc> i would assume that the peer id is unnecessary with the ip and port anyway[05:53:35] <TheSHAD0W> Yes.[05:53:39] <Arc> since even if two clients are running on the same host they'll have different ports[05:53:41] <Arc> ok[05:54:14] <Arc> yea im not supporting compact because it doesnt do ipv6[05:54:15] <TheSHAD0W> Actually.[05:54:23] <TheSHAD0W> Clients may run multiple torrents on the same port.[05:54:28] <Arc> (and the tracker's server has unlimited bandwidth)[05:54:36] *** Gottaname has quit IRC[05:54:39] <Arc> yes, but in the tracker's records, they are the same peer[05:55:00] <TheSHAD0W> But the incoming connection will send the infohash, which lets the peer figure out which torrent and which peer id to send.[05:55:18] <TheSHAD0W> Well.[05:55:22] <Arc> the use case i'm writing this for has maybe (maybe) 100 peers at a time, but 70k torrents[05:55:39] <TheSHAD0W> You should keep separate lists for each torrent, IMO, and not consider peer ID collisions between torrents.[05:55:56] <TheSHAD0W> And not code so peer ID collisions would cause problems.[05:56:49] <Arc> im indexing peers by ip+port anyway[05:57:04] <TheSHAD0W> As I said, that's insufficient.[05:57:09] <Arc> why?[05:57:15] <TheSHAD0W> A peer may be running multiple torrents with the same IP/port.[05:57:21] <Arc> so?[05:57:38] <TheSHAD0W> Okay, so you have a separate index for each torrent?[05:57:42] <Arc> yes[05:57:47] <TheSHAD0W> Then no problem.[05:59:07] <Arc> really the peer is just to record timeout[05:59:40] <Arc> if the peer isnt heard from in so long, they're removed, assuming the client closed/crashed uncleanly[06:00:23] <Switeck> or decides to go into seed-only mode?[06:00:52] <Arc> they still need to announce periodically[06:01:21] <Arc> otherwise trackers would get littered by seeds that went offline[06:03:07] <Switeck> problem I hear about alot is ghost peers (that are now seeds)[06:03:20] <Switeck> people complain there's lots of peer on a torrent but they never connect to more than 3[06:03:41] <Switeck> (private trackers almost 100%)[06:04:03] <Arc> well in this network almost all the torrents have just two seeds which are quite public[06:11:03] <Arc> oh btw, what are the boolean parameters set by[06:11:10] <Arc> no_peer_id=1?[06:11:24] <Arc> or just &no_peer_id& by itself[06:12:20] <Arc> and unrelated, any modern client should handle a tracker returning a HTTP moved permanently code properly, right?[06:14:50] <Switeck> yes[06:15:10] <Switeck> (doesn't mean they do!)[06:15:25] <Arc> i guess we'll find out[06:15:33] <Arc> i could always just internally handle it[06:15:51] <Arc> the torrents are all pointing at /announce.php and im redirecting them to /announce[06:16:27] <Arc> so what would a url containing no_peer_id look like?[06:16:49] <TheSHAD0W> no_peer_id=1[06:16:53] <TheSHAD0W> Or compact=1[06:16:55] <Arc> cool thanks[06:17:11] <Arc> if compact=1 can i assume that no_peer_id is also 1?[06:17:12] <TheSHAD0W> Peers may send both.[06:17:19] <TheSHAD0W> No, you can't...[06:17:33] <TheSHAD0W> But compact is preferable for you to return than no_peer_id.[06:17:42] <Arc> ok. so if they send compact=1 but do not send no_peer_id i should tell them "unsupported"[06:17:52] <TheSHAD0W> No, no...[06:17:55] <Arc> not unless there's now a ipv6 compact[06:18:01] <TheSHAD0W> There is.[06:18:02] *** ProperN[out] has joined #bittorrent[06:18:05] <Arc> oh? url please[06:18:15] <TheSHAD0W> Oh, you're writing an ipv6 only tracker?[06:18:26] *** ProperN[out] has quit IRC[06:18:26] *** ProperN[out] has joined #bittorrent[06:18:26] <Arc> no, but im putting heavy emphasis on ipv6 in it[06:18:29] <TheSHAD0W> Should be up as a BEP.[06:18:39] <TheSHAD0W> Compact is better than no_peer_id.[06:19:01] <Arc> yes, but if i dont support clients without no_peer-id, if they specify compact and not no_peer_id, i should refuse them?[06:19:19] <TheSHAD0W> http://bittorrent.org/beps/bep_0007.html[06:19:32] <TheSHAD0W> You should send them IPv4 peers only.[06:19:40] <Arc> the problem is if my peer list has both ipv4 and ipv6 entities in it, i wont be able to return any ipv6 entities[06:19:55] <TheSHAD0W> Correct.[06:20:00] *** ProperNoun has quit IRC[06:20:02] <TheSHAD0W> You'll have to filter it.[06:20:05] *** ProperN[out] is now known as ProperNoun[06:20:09] <TheSHAD0W> There are a few strategies for doing so.[06:20:59] <TheSHAD0W> Note that you'll have to send IPv4 and IPv6 data separately anyway.[06:21:57] <Arc> oh?[06:22:22] <TheSHAD0W> Read the BEP.[06:23:20] <Arc> oh i see[07:10:06] *** chelz has joined #bittorrent[07:15:48] *** Switeck has quit IRC[08:46:48] *** ygrek has joined #bittorrent[09:30:01] *** e-manuel has joined #bittorrent[09:53:37] *** ygrek has quit IRC[10:11:00] *** ygrek has joined #bittorrent[10:11:16] *** edigaryev has joined #bittorrent[10:18:07] * alus hugs TheSHAD0W[10:30:27] *** e-manuel has left #bittorrent[10:38:17] *** medecau has joined #bittorrent[10:47:41] *** chelz has quit IRC[12:36:05] *** e-manuel has joined #bittorrent[13:12:50] *** goussx has joined #bittorrent[13:17:38] *** e-manuel has quit IRC[13:18:02] *** ProperN[out] has joined #bittorrent[13:18:14] *** ProperN[out] has quit IRC[13:18:14] *** ProperN[out] has joined #bittorrent[13:21:01] *** ProperNoun has quit IRC[13:21:03] *** ProperN[out] is now known as ProperNoun[14:26:50] *** wojci has quit IRC[15:12:29] *** ProperN[out] has joined #bittorrent[15:12:41] *** ProperN[out] has quit IRC[15:12:41] *** ProperN[out] has joined #bittorrent[15:14:24] *** ProperNoun has quit IRC[15:14:25] *** ProperN[out] is now known as ProperNoun[15:48:43] *** unixSnob has joined #bittorrent[15:49:32] <unixSnob> suppose you have a torrent with 1000+ files, and half of them downloaded before the torrent died.[15:49:46] <unixSnob> how do you delete the files that did not complete?[15:50:21] <The_8472> tell your torrent client to delete them[15:51:37] <unixSnob> ha.. rtorrent doesn't understand that instruction[15:52:01] <unixSnob> it's all or nothing with rtorrent[15:52:16] <mpl> uh, no.[15:52:29] <unixSnob> what would be a lightweight torrent client that can handle this?[15:52:32] <mpl> you just go in the file view and you set the files you want to "off".[15:53:12] <unixSnob> mpl: "off" just tells it not to download files in the first place.. it doesn't mean delete the file[15:53:25] <mpl> so what?[15:53:35] <mpl> if they're not downloaded what's the difference to you?[15:54:07] <unixSnob> mpl: the difference is separation.. I want the broken/incomplete files to be removed[15:55:06] <mpl> so just delete them. why do you want the torrent client to do that when you can do it yourself?[15:55:47] <mpl> I must be missing something because I don't understand your problem...[15:55:48] <unixSnob> pick through 1000 files and delete them manually? I'm not a grunt. I'd rather delete them all before it comes to that[15:56:06] <unixSnob> I just want to keep the files that completed[15:56:07] <DWKnight> why not just pester the site you got the torrent from for a reseed?[15:56:54] <unixSnob> DWKnight: it's old, and it's a private site, so whoever still has these files probably doesn't have the torrent file anymore[15:56:54] <mpl> oh I see, you can't discriminate which files to delete without the help of the torrent client. fair enough.[15:57:42] <DWKnight> if it's a private site, they should have somebody[15:58:07] <mpl> well if the .torrent contains the md5sums you could make a small program that runs them against the files you have on disk...[15:58:35] <unixSnob> DWKnight: the site eliminated the .torrent file itself as well.. there's no record of it, so someone would have to reproduce the same hash[15:59:35] <unixSnob> mpl: yeah, that would perhaps be possible.. I didn't realize the hashes existed for each file[15:59:42] <unixSnob> I thought it was one hash for the whole lot[15:59:51] <DWKnight> not all torrents include per-file hashes[16:00:05] <mpl> no they don't. the hashes are for blocks. but sometimes you have the md5sums yes.[16:00:08] <DWKnight> and you have the .torrent file already, so there's nothing to reproduce, just supply the .torrent[16:00:35] <unixSnob> ah, yeah, forgot I have to torrent file myself[16:11:39] *** burris has quit IRC[16:17:22] *** burris has joined #bittorrent[16:42:25] *** Switeck has joined #bittorrent[16:44:22] <The_8472> iirc Az has the option to fully delete files marked as "delete" on torrent removal[16:44:53] <The_8472> although i don't use that option myself[16:45:55] <unixSnob> by "Az" do you mean Vuze?[16:47:22] <The_8472> yes[18:06:45] <TheSHAD0W> unixSnob: If you can get BitTornado running on those files, and either set it to preallocate or hit the "finish allocation" button, it will fix those files for you.[18:07:57] <TheSHAD0W> Only the GUI version will tell you which files are complete, though.[18:09:44] <TheSHAD0W> And you can delete the incomplete ones through BitTornado as well.[18:15:32] <unixSnob> okay, thanks[18:19:10] <unixSnob> TheSHAD0W: how does it fix incomplete files?[18:19:34] <unixSnob> TheSHAD0W: someone would have to be seeding the torrent, correct?[18:19:47] <TheSHAD0W> It can't fix incomplete ones, but if data for the complete ones is present or out of place, it will move it into place.[18:20:00] <TheSHAD0W> Er, present but out of place*[18:21:04] <TheSHAD0W> I'm not sure how rtorrent stores data during download.[18:21:34] <unixSnob> the data goes straight to the file. If a file is 100% complete, then it's ready to use[18:21:50] <TheSHAD0W> Oh, okay.[18:21:53] <TheSHAD0W> Never mind then.[18:22:04] <unixSnob> so it seems bittornado will perhaps work to remove the incomplete files[18:22:12] <TheSHAD0W> Yes...[18:22:35] <TheSHAD0W> Run it, then hit "Details". It'll have a list of all the files showing range of completeness for each.[18:23:17] <TheSHAD0W> Right-click the files that aren't complete (you can pre-select them), set them to disabled (delete).[18:23:27] <TheSHAD0W> Then close the program, and the incomplete files will go away.[18:23:40] <unixSnob> okay, thanks[18:30:33] <unixSnob> i got an error.. "ordinal not in range", and then it dumps python code in a dialog box[18:32:03] <TheSHAD0W> X_X[18:32:35] <TheSHAD0W> Sorry. BitTornado can't handle torrent files that aren't in spec very well.[18:32:57] <TheSHAD0W> That's an issue in the Python libraries, I think.[18:33:10] <TheSHAD0W> Vuze may be able to do it also... Not sure.[18:33:14] <unixSnob> it seemed to take the torrent file, but crapped out when I told it where the files are[18:33:22] <TheSHAD0W> Yeah.[18:33:35] <DWKnight> wiki.theory.org is now more useful than the BEPs again[18:33:49] <TheSHAD0W> Some file in the torrent has a high-ASCII character, and when it asks the Python libraries to open it, kablooey.[18:34:08] <DWKnight> or is that a "still" instead of an "again"?[18:34:53] <TheSHAD0W> DWK: The BEPs are a bit abrupt in their explanations, but that's true of all the internet proposal setups.[18:35:12] <DWKnight> someone went through to clean up and removed important stuff though[18:35:19] <TheSHAD0W> Oops.[18:35:38] <TheSHAD0W> Mmm, maybe they ought to be stored in wiki format then.[18:40:08] *** Andrius has joined #bittorrent[18:54:57] <The_8472> <DWKnight> someone went through to clean up and removed important stuff though <- like?[18:57:58] <DWKnight> I'm looking at things and the readability at least is worse[18:58:04] <TheSHAD0W> I also have a comment on BEP007...[18:58:05] <TheSHAD0W> http://bittorrent.org/beps/bep_0007.html[18:58:13] <The_8472> "Last-Modified: 2008-05-21 00:08:51 -0700 (Wed, 21 May 2008)"[18:58:16] <The_8472> so... nothing changed[18:58:27] <TheSHAD0W> It includes a key ipv4, which basically duplicated the key ip.[18:59:00] * The_8472 points at alus he's maintaining it[19:03:10] <The_8472> DWKnight, an example of what's missing would help[19:04:06] <TheSHAD0W> (Should also note that I'm the one who originally proposed the IPv6 extensions... http://forums.degreez.net/viewtopic.php?p=28193)[19:07:23] <TheSHAD0W> And I still believe the peer should preferably connect to the tracker via IPv4, so the tracker can sniff the peer's external IP.[19:09:03] * The_8472 can't wait for the day when the ipv4 pools are all exhausted[19:09:55] <TheSHAD0W> Might not happen.[19:10:25] <The_8472> i doubt that[19:14:59] <mpl> TheSHAD0W: I'm curious, how could it not happen? excluding end of the world scenarii oc.[19:15:53] <TheSHAD0W> Because the ISPs know it's coming, and should start offering IPv6 service any time now.[19:16:16] <TheSHAD0W> Don't IPv4 addresses cost money?[19:16:47] <The_8472> sure, but so does changing their infrastructure[19:17:00] <TheSHAD0W> Their infrastructure is already largely changed.[19:17:27] <The_8472> so, if you aim for quarterly results then you don't want the expenses until you can justify them[19:17:27] <mpl> ah I thought you meant non exhaustion of ipv4 address, _without_ switching to ip6.[19:17:51] <The_8472> the last mile infrastructure hasn't been changed[19:18:02] <The_8472> they're not handing out ipv6 addresses to customers[19:18:13] <The_8472> many of them don't even announce ipv6 via bgp[19:18:39] <TheSHAD0W> Last mile is a small problem for some cable systems. For DSL systems, which largely use PPPoE, it's a matter of software.[19:19:09] <The_8472> router software. for possibly some old, largely unmaintained models[19:19:19] <Switeck> Some ADSL ISPs are still putting DSLAMs on T-3's[19:20:42] <Switeck> I don't know if that makes handing out ipv6 addresses to their customers harder or not tho...just means a bandwidth pinch[19:21:25] <The_8472> still, if you're a big ISP then you have to roll out changes to your entire infrastructure. and your customers. that's a customer service nightmare[19:21:36] <The_8472> because something certainly will go wrong somewhere[19:42:42] <TheSHAD0W> Mmm...[19:43:22] <TheSHAD0W> Cable systems could switch to PPPoE also, to be able to handle IPv6.[19:43:38] <TheSHAD0W> (Basically just using a local version of teredo...)[19:45:33] <TheSHAD0W> Easiest way to switch would be to switch the last mile over to a non-routeable address and perform NAT for customers who don't want to do anything, then give PPPoE access for IPv4 and Teredo for IPv6 for anyone who wants/needs an exposed IP.[19:47:09] <TheSHAD0W> PPPoE and Teredo are both readily available on individual PCs, and PPPoE on routers. Teredo-equipped IPv6 routers would be desirable.[20:14:03] <The_8472> teredo? no[20:14:12] <The_8472> 6to4 or 6RD should go on routers[20:14:17] <The_8472> teredo is crap[20:16:55] <TheSHAD0W> Sorry.[20:17:12] *** MassaRoddel has joined #bittorrent[21:10:52] *** ProperN[out] has joined #bittorrent[21:10:57] *** ProperN[out] has quit IRC[21:10:57] *** ProperN[out] has joined #bittorrent[21:12:28] *** ProperNoun has quit IRC[21:12:29] *** ProperN[out] is now known as ProperNoun[21:31:14] *** edigaryev has quit IRC[22:12:42] *** unixSnob has quit IRC[22:20:35] *** cgreco has joined #bittorrent[22:20:35] *** cgreco has joined #bittorrent[22:29:39] <incant> pwd[22:29:45] <incant> dammit :-\[22:40:01] *** Randor has joined #bittorrent[22:56:08] *** Randor has left #bittorrent[23:01:55] *** ygrek has quit IRC[23:19:02] <mpl> http://5ttt.org/[23:20:35] *** chelz has joined #bittorrent[23:55:30] *** Andrius has quit IRC