logs | stats
   January 5, 2008  
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 | 31

[00:08:53] *** thewird has joined #bittorrent
[00:09:33] *** funkywizard has joined #bittorrent
[00:10:15] <funkywizard> hello everyone
[00:15:25] <rcjsuen> funkywizard: Hi
[00:16:53] <funkywizard> I'm wanting to start a service that involves bittorrent
[00:17:05] <funkywizard> and doing some research to see if theres anything out there similar to what I'm thinking of doing
[00:17:26] <funkywizard> what I'd like to do is, you upload a .torrent file on a website, and the webserver downloads the torrent for you and gives you an http link
[00:17:30] <funkywizard> for a direct download
[00:17:43] <funkywizard> now, I did find one site that offers such a service, but the owners aren't looking to sell it :P
[00:18:02] <kjetilho> eh, wow.  I hope you know some good lawyers.
[00:18:10] <funkywizard> well
[00:18:13] *** EvolutionCrazy has joined #bittorrent
[00:18:20] <funkywizard> technically it falls under the caching proxy exemption of the DMCA
[00:18:27] <ShadowJK> There are lots of clients that do it on a "personal" level
[00:18:30] <kjetilho> yeah right.  good luck with that.
[00:18:32] <funkywizard> wether I get sued or not, hard to say, but it is a legally defensible position
[00:18:52] <funkywizard> yeah, I did notice things like torrentflux, but its not geared towards a subscriber model like rapidshare is
[00:19:24] <funkywizard> and the bigger issue is that if multiple people want the same torrent there doesn't seem to be a good way in those programs to merge the requests or cache the content for each
[00:19:29] <kjetilho> notice how rapidshare is not based in the US
[00:19:37] <funkywizard> true enough
[00:19:42] <funkywizard> I actually was looking into them
[00:19:56] <funkywizard> a lot of these companies are incorporated in the british virgin islands
[00:20:11] <funkywizard> with servers in some of the more liberal places in europe
[00:20:56] <funkywizard> regardless of the legalities of the situation, right now im more worried about the technical aspects, insofar as building something from scratch would involve a lot more programming than I would prefer
[00:21:07] <funkywizard> I would rather pay for a solution, or even a head start, than start from scratch
[00:21:51] <thewird> hey DeHackEd, you around :)
[00:22:33] <ShadowJK> scaling it up is what would worry me :-)
[00:22:41] <funkywizard> thats the fun part :D
[00:22:47] <thewird> that is the issue at hand :)
[00:22:52] <funkywizard> actually
[00:23:00] <funkywizard> i know what i want to do with that ;)
[00:23:07] <thewird> :P
[00:23:11] <funkywizard> a combination of mogilefs and squid should handle it up to a good number of servers
[00:23:26] <ShadowJK> I guess it'd be a few minutes to hack together some script that dumped uploaded .torrent files into a directory that a bittorrent client was monitoring...
[00:23:41] <ShadowJK> But make it work sensibly when you've got more than 5 users.. :)
[00:23:49] <kjetilho> the main issue is subscription trackers
[00:23:58] <funkywizard> yeah, i was thinking of them
[00:24:00] <ShadowJK> ah those too...
[00:24:09] <funkywizard> I'd probably have to arrange something with the owners to allow my subnet implicitly
[00:24:35] <funkywizard> Maybe work something out where I agree to serve a high ratio in exchange for a blanket allowance on my ip range
[00:25:15] <funkywizard> but yeah, as far as the torrents go, when uploading a torrent it would have to check a database to see if those files had already been downloaded before
[00:25:26] <ShadowJK> kjetilho, hey let's start a rumor that RIAA/MPAA is trying to gain access to IPs of private tracker users by pretending to be doing caching? ;)
[00:25:40] <funkywizard> nice :(
[00:25:42] <funkywizard> lol
[00:25:47] <ShadowJK> :)
[00:26:05] <funkywizard> i want to have a combination free / subscription service
[00:26:08] <ShadowJK> I don't think rumor is needed, some of them have paranoia built-in :)
[00:26:19] <funkywizard> free would have similar restrictions to rapidshare
[00:26:50] <ShadowJK> the torrents have infohash that's suitable to use for checking duplicates, i guess
[00:26:58] <funkywizard> that's what i would figure
[00:27:09] <kjetilho> ShadowJK: you could/should go further than that.
[00:27:37] <funkywizard> once a torrent is done, I would take all the files that make it up, put some location info into a database, and send them off to a mogileFS cluster
[00:27:43] <kjetilho> a friend of mine is into e-books.  he sees a 1:4 duplication rate since it's common to do different collections...
[00:27:50] <DeHackEd> thewird: ?
[00:28:00] <funkywizard> yeah i'd want to do the caching and stuff per-file
[00:28:12] <ShadowJK> kjetilho, if only there were per-file hashes in the .torrent :(
[00:28:13] <funkywizard> i know some bittorrent clients where you can specify you want to download particular files from the torrent and not others
[00:28:18] <funkywizard> hey HeHackEd
[00:28:25] <funkywizard> DeHackEd
[00:28:28] <funkywizard> long time no see
[00:28:29] <kjetilho> ShadowJK: indeed.  but it's just a little CPU wastage, not a biggie
[00:28:43] <ShadowJK> kjetilho, i mean so you could check before you download same file a second time
[00:28:46] <funkywizard> yeah I figure bandwidth will be the biggest cost so on a quad core system no big feal
[00:28:50] <kjetilho> ShadowJK: I just realised that
[00:28:57] <thewird> hey DeHackEd
[00:28:58] <kjetilho> yes, it's a shame
[00:29:00] <funkywizard> aren't there per file hashes in the torrent?
[00:29:03] <thewird> not sure you remember me?
[00:29:05] <ShadowJK> funkywizard, not exactly
[00:29:14] <funkywizard> i guess its per chunk then?
[00:29:17] <ShadowJK> yep
[00:29:24] <DeHackEd> thewird: you wanted to make your own bitcache site
[00:29:31] <funkywizard> and the chunks dont necessarily lie on file boundaries
[00:29:34] <kjetilho> right
[00:29:36] <DWKnight> some torrents do include per-file hashes, but not all
[00:29:45] <funkywizard> well that makes it harder to avoid duplicate downloading
[00:29:46] <funkywizard> but
[00:29:52] <funkywizard> you could still avoid duplicate file storage
[00:29:53] <thewird> we're finally serious about starting it
[00:30:17] <funkywizard> CRC the resulting files after download and only insert new ones into the storage cluster
[00:30:33] <ShadowJK> CRC? Please...
[00:30:41] <funkywizard> or equivalent
[00:30:52] <ShadowJK> sha1 or better
[00:30:59] <thewird> DeHackEd: you said you had something almost ready before, you still have that?
[00:31:01] <funkywizard> whatever the technically sound equivalent is
[00:31:21] <DeHackEd> I should
[00:31:39] <funkywizard> I've been working on setting up mogile on a test system
[00:31:48] <funkywizard> but got kinda side tracked trying to pick up women
[00:31:53] <thewird> lol
[00:31:54] <funkywizard> :P
[00:32:24] <thewird> DeHackEd: how ready is it and what needs doing?
[00:32:57] <DeHackEd> a thorough testing mostly
[00:33:04] <thewird> :)
[00:33:09] <DeHackEd> I think it handled some basic tests though, but I have no idea how well it'll scale
[00:33:14] <funkywizard> see, the site i'd like to clone is furk.net
[00:33:15] <thewird> is it uploaded anywhere?
[00:33:19] <funkywizard> I like scaling things
[00:33:30] <DeHackEd> yeah, the computer I'm sitting in front of
[00:33:32] <funkywizard> the big issue will be avoiding duplicated downloading and storage
[00:33:34] <funkywizard> lol
[00:33:51] <thewird> need a place to upload it?
[00:34:04] <DeHackEd> no. I can handle it.
[00:34:11] <funkywizard> lol wird
[00:34:24] <The_8472> <funkywizard> but yeah, as far as the torrents go, when uploading a torrent it would have to check a database to see if those files had already been downloaded before <- well, not really necessary, "normal" bittorrent clients already know if they have downloaded somethingbased on the hash
[00:35:15] <The_8472> anyway, what you need is accounting and .torrent management / associating .torrents with downloaded files and returning them
[00:35:18] <funkywizard> well, the thing gets more complicated because, after reaching the desired upload ratio, its going to move the files off of the server that did the torrenting in the first place
[00:35:32] <The_8472> the bittorrenting part can be done by some scripts and "normal" clients running on a clister
[00:35:42] <funkywizard> and there will be multiple servers doing torrenting
[00:35:53] <DeHackEd> which is part of what I wrote for thewird
[00:35:59] <funkywizard> oh, nice
[00:36:22] <The_8472> but so far all of the torrent-related functionality you describe already exists in some clients
[00:36:39] <funkywizard> yeah, I mean, I think originally wird told me you'd make the thing for us for free, but I don't think thats fair given we want to make a subscription service out of it
[00:36:44] <thewird> DeHackEd: could we see the code in action somehow?
[00:36:46] <funkywizard> I'd be glad to pay for the script
[00:36:58] *** K`Tetch has quit IRC
[00:37:06] <funkywizard> The_8472: hmm
[00:37:41] <funkywizard> first off, I don't know a lot about different BT clients. Also, im just not sure how to distribute that functionality among multiple servers
[00:37:45] <DeHackEd> thewird: one of the most annoying parts of my life is that my sister owns a high-maintenance dog, and then leaves for nights on end and dumps the job of watching him on me. so how about we wait an hour while I do something approximating my "responsibility" and then I set it off.
[00:37:57] <funkywizard> hahaha
[00:38:10] <DeHackEd> it's true.
[00:38:16] <funkywizard> ah man, gotta suck
[00:38:20] <funkywizard> good luck with that
[00:38:41] <thewird> nice ill be here all night
[00:38:41] <DeHackEd> apparently she thinks she can just dump aynthing on me she wants
[00:38:50] <DeHackEd> and the annoying thing is I end up doing it anyways.
[00:38:55] <thewird> is it a big dog ?
[00:38:59] <DeHackEd> german shepherd
[00:39:25] <DeHackEd> and he's young enough that he's excitable
[00:39:52] <kjetilho> one of the most intelligent dogs around, though
[00:39:53] <thewird> hehe
[00:40:02] <kjetilho> ... with age :)
[00:40:16] <The_8472> funkywizard, the only thing you can't do is matching files from different torrents... you can add some early-detection logic by comparing file sizes and the first few KB (once they're downloaded), but there is no good way to tell if two different torrents share some file atm
[00:40:38] <funkywizard> ah ok
[00:40:56] <kjetilho> prioritising downloads in the queue seem the most tricky problem to me
[00:41:06] <funkywizard> would a torrent have the same infohash if it had the same files but had other things different like.... say which trackers it was assigned to and such?
[00:41:08] <kjetilho> you can't assume there will be an abundance of resources
[00:41:29] <DeHackEd> funkywizard: "which tracker" is about the only variable that can change and keep the info_hash the same. other things can change the info hash though
[00:41:34] <kjetilho> if the files are exactly the same and are in the same order, yes.
[00:41:41] <DeHackEd> such as selection of piece size, capitalization of the filename, etc.
[00:41:48] <The_8472> and the same piece size and the same file names in case it's a multifile torrent
[00:41:51] <kjetilho> oh, piece size..
[00:42:01] <thewird> ah
[00:42:02] <DeHackEd> yeah piece size can be a killer
[00:42:03] <The_8472> filenames are also an issue, stuff often gets renamed
[00:42:07] <funkywizard> alright, so, my options are, .torrent file is identical (save for which trackers are set), or, I do some voodoo magic after downloading a small portion of a file
[00:42:39] <DeHackEd> off I go
[00:42:46] <The_8472> the worst i have seen were about 6-8 public torrents sharing the same file(s) +- some disclaimler files +- private flag + differnet file names + different piece sizes
[00:43:06] <funkywizard> great....
[00:43:07] <funkywizard> lol
[00:43:13] <thewird> it can get worse ^_^
[00:43:18] <The_8472> and that doesn't include private torrents ^^
[00:43:28] <The_8472> and then consider batch torrents
[00:43:36] <thewird> especially with anime where they batch it up
[00:43:37] <thewird> yah
[00:43:46] <funkywizard> so what you're saying is my cache hit rate won't be as good as i'd hope on the torrenting side
[00:43:55] <The_8472> 1 big, multigigabyte torrent that contains something that was partially realeased earlier + some new stuff
[00:43:59] <kjetilho> funkywizard: it's not really voodoo.  you can keep hashes for say every 8 KiB in the file.  when you download 16 KiB of the new torrent, you will find a stretch of at least 8 KiB which are aligned, and you can compare that to your list
[00:44:02] <funkywizard> i dont see any reason i cant figure out whats what after the files are downloaded in order to minimize my long term storage requirements though
[00:44:34] <kjetilho> of course just one such hash hit (plus file size) is a bit risky...
[00:44:35] <funkywizard> ah
[00:44:36] <The_8472> kjetilho, it would still need some work
[00:44:41] <funkywizard> hmm
[00:44:44] <funkywizard> what i could do.....
[00:44:59] <funkywizard> ok say theres a hash for each "piece" in a file
[00:44:59] <The_8472> but he's right... files often get tiny modifications
[00:45:05] <The_8472> think of id3 tags in mp3s
[00:45:10] <funkywizard> and the torrent makes it easy enough to identify which pieces belong to which files right?
[00:45:17] <funkywizard> i mean
[00:45:22] <funkywizard> a piece might belong to more than one file of course
[00:45:33] <funkywizard> but for a large file, there will be a given number of pieces that only belong to that file
[00:45:38] <The_8472> yes
[00:45:46] <funkywizard> so its a matter of figuring out what the offset is
[00:45:54] <The_8472> the problem is alignment
[00:45:56] <kjetilho> if two pieces have the same hash, it's safe to assume the data is identical.
[00:46:00] <funkywizard> and comparing the hashes against hashes of same size files for those same pieces
[00:46:16] <The_8472> alignment and piece sizes
[00:46:25] <The_8472> different piece sizes => completely different hashes
[00:46:35] <funkywizard> so i pick out all the "pieces" that belong only to a particular file, figure out what the offset is, and compare it to the hashes that would be generated by same sized files I already have
[00:46:47] <The_8472> different alignment (due to inserted files or reordering) => different hashes
[00:46:58] <funkywizard> right
[00:47:10] <The_8472> but yeah, you might safe some effort there
[00:47:27] <funkywizard> if theres different alignments, then I have to take all my completed files with the same size, and generate new hashes for say, the first piece for each
[00:47:34] <funkywizard> and among those where the first piece matches
[00:47:42] <funkywizard> generate hashes for all the other pieces
[00:47:48] <The_8472> but the files would have to be 100% identical, as i said... often some smaller pieces get modified while the remaining file stays intact
[00:48:21] <The_8472> feasible, but lots of work
[00:48:22] <kjetilho> funkywizard: problem is you have to do it for *all* your completed files.  well, you can filter on file size.  but then you'll miss out on files where the credits at the end have been cut.
[00:48:49] <funkywizard> well, i dont mind missing out on files where credits have been cut
[00:48:56] <funkywizard> i want people to get exactly what they're trying to download
[00:49:09] <funkywizard> and yeah, it would be a big hassle from the point of view that complexity increases as total files stored increases
[00:49:09] <The_8472> well, but that means you can't reuse pieces you already have
[00:49:13] <funkywizard> disk i/o would be a monster
[00:49:16] <kjetilho> yes, but you could get by with reusing the first 80% of the file if you do it right
[00:49:37] <funkywizard> right
[00:49:38] <funkywizard> but
[00:49:45] <The_8472> you'd basically need a database for piece hash <-> file lookups
[00:49:50] <funkywizard> i think its more important to merge identical files than try to save on fringe cases
[00:50:02] <The_8472> probably
[00:50:09] <funkywizard> the problem being that if the offset changes, all the hashes change
[00:50:13] <funkywizard> like you said
[00:50:24] <funkywizard> so i really have to generate new hashes based on piece size and offset
[00:50:45] <The_8472> yeah, but you can probably eleminate most of the files by size and the first properly-aligned hash
[00:50:55] <kjetilho> you could use my table of aligned hashes idea to make a short list of potential files.
[00:51:00] <kjetilho> that should be pretty cheap.
[00:51:01] <funkywizard> which hopefully won't be too intensize
[00:51:02] <funkywizard> *intensive
[00:51:48] <The_8472> kjetilho, you can't do that... with 4MB pieces you'd have 4 million possible alignments for a single file...
[00:51:56] <funkywizard> right
[00:51:57] <The_8472> that's 80MB of hashes ^^
[00:52:02] <kjetilho> The_8472: *aligned*
[00:52:05] <funkywizard> but you can create the hashes on the fly
[00:52:12] <kjetilho> even if it's unaligned in the original torrent
[00:52:25] <The_8472> well, then you'd have to download stuff first
[00:52:34] *** `Shadow` has joined #bittorrent
[00:52:35] <The_8472> instead of comparing it to the hashes of a .torrent
[00:52:39] <The_8472> before you start to download it
[00:52:48] <funkywizard> welcome Shadow
[00:52:50] <`Shadow`> yo
[00:52:54] <kjetilho> yes, you have to download eniugh consecutive data to get one aligned block
[00:53:09] <The_8472> which an be problematic if the availability is low for example
[00:53:12] <`Shadow`> You guys already probably said this, but why not just compare the hashes from the .torrent file and if it already exists on the server, use that copy
[00:53:16] <The_8472> so doing it offline might be better
[00:53:30] <The_8472> `Shadow`, yes... we already did :)
[00:53:33] <`Shadow`> :p
[00:53:48] <funkywizard> we plan to do that, people are saying there aren't any per-file hashes
[00:53:50] <kjetilho> *shrug* if availability is that low, I don't think the users will be happy to have to wait for days for the files anyway
[00:53:59] <funkywizard> and that the number of torrents that share identical files but are not identical torrents is fairly high
[00:54:03] <`Shadow`> Why do you care about per file?
[00:54:05] <`Shadow`> hmm
[00:54:09] <The_8472> funkywizard, some torrents include them... that would make things easier for you, but not that many i think
[00:54:10] <`Shadow`> Really?
[00:54:13] <`Shadow`> I'd disagree with that
[00:54:24] <funkywizard> i dont know if its the case or not
[00:54:25] <`Shadow`> How often do you download torrents with the same file in each torrent but a bunch of different files
[00:54:30] <funkywizard> but thats the assumption under which our discussion is heading
[00:54:40] <funkywizard> well i only download one of them
[00:54:41] <funkywizard> but
[00:54:42] <`Shadow`> If you want to reduce storage, you could hash each file once its downloaded and then remove dupes
[00:54:43] <DWKnight> those ones that do
[00:54:45] <kjetilho> `Shadow`: it's very dependent on the type of media
[00:54:46] <The_8472> `Shadow`, i can show you a perfect (albeit illegal) example :)
[00:54:49] <funkywizard> if i have 1000 users, some of them will pick one torrent and some another
[00:54:53] <DWKnight> account for less than .1% of torrents out there
[00:54:58] <`Shadow`> gimme an example?
[00:55:03] <funkywizard> <`Shadow`> If you want to reduce storage, you could hash each file once its downloaded and then remove dupes
[00:55:05] <funkywizard> definitely plan to do that
[00:55:18] <The_8472> vtv and eztv tv-torrents. they basically release the same, byte-identical episodes with different filenames and piece sizes
[00:55:29] <The_8472> and they are damn popular
[00:55:34] <`Shadow`> really? never noticed that
[00:55:38] <`Shadow`> but i dont really pay much attention
[00:55:40] <funkywizard> hehe
[00:55:42] <kjetilho> The_8472: but they are single file torrents, aren't they+
[00:55:43] <funkywizard> neither do i
[00:55:44] <kjetilho> ?
[00:55:44] <funkywizard> but
[00:55:46] <`Shadow`> anyone know their reasoning for that?
[00:55:47] <funkywizard> seems reasonable
[00:56:05] <kjetilho> oh, piece sizes again :)
[00:56:07] <funkywizard> changing the filenames can be a matter of bigger-dick. put your clan tag on the file
[00:56:13] <The_8472> kjetilho, yes... but then think of demonoid... they always added "torrent by demonoid"-file to the torrent...
[00:56:14] <`Shadow`> anyways, if the protocol doesn't specify per file hashes, then there's not really alot you can do, so suck it up :)
[00:56:17] <funkywizard> and creating a new .torrent, maybe one site has one default and the other the other default
[00:56:39] <The_8472> so there is lots of redundancy out there
[00:56:53] <`Shadow`> what are you more concerned about? storage or b/w?
[00:56:56] <`Shadow`> cause storage is cheap
[00:56:58] <`Shadow`> relatively
[00:57:01] <funkywizard> well, what we were talking about is downloading enough of a given file to figure out where the pieces align, and figuring out what the hash would be for that piece for any other file we have already of the same size
[00:57:37] <`Shadow`> My suggestion would be to just not worry about it until it becomes an issue down the road....... you aren't going to have enough users immediately for it to be a major problem
[00:57:38] <funkywizard> the main issue i want to avoid is downloading the same thing multiple times. for b/w reasons partly, but mostly for higher quality of service. if you can get the torrent onto the server faster, users can start downloading it faster
[00:58:00] <The_8472> it can be done w/o downloading too, but then you'd have to generate the hashes on the fly instead of using a database due to alignment problems, that would be the difference
[00:58:01] <funkywizard> oh yeah, definitely. i dont need to solve all the issues immediately
[00:58:10] <`Shadow`> you can possibly avoid this by letting users see what other users have downloaded, but this will open you up to legal issues
[00:58:13] <The_8472> one can use a database of precalculated hashes, the other one doesn't require downloading to check
[00:58:21] <thewird> `Shadow`: you'd be surprised how soon it will be an issue
[00:58:25] <funkywizard> yeah, i dont want the legal issues for that
[00:58:28] <`Shadow`> what country are you planning on hosting this in?
[00:58:31] <funkywizard> well
[00:58:40] <funkywizard> I'm hoping to use the DMCA caching proxy exemption law
[00:58:46] <funkywizard> and host at FDCServers.net
[00:58:51] <`Shadow`> yeah ok
[00:58:54] <`Shadow`> that might work
[00:58:56] <funkywizard> because technically speaking this is a caching proxy service
[00:59:08] <`Shadow`> i was thinking of just using the "network provider" rules saying that you are just passing the data along
[00:59:10] <funkywizard> which is exempted from liability so long as we respond properly to DMCA requests
[00:59:19] <funkywizard> that too
[00:59:22] <`Shadow`> the problem is, because you are switching the protocols, it might not be considered such
[00:59:25] <funkywizard> "automated service" exemption
[00:59:28] <funkywizard> right
[00:59:31] <funkywizard> this is true
[00:59:39] <funkywizard> i figured though, if easynews can get away with it, we can too
[00:59:43] *** backz has joined #bittorrent
[00:59:48] <funkywizard> it might be preferable to do the actual torrenting in another facility
[00:59:55] <funkywizard> in amsterdam
[01:00:08] <`Shadow`> yeah, but i'd also like to point out that other major news provider that just got major shit because they were pretty much advertising it as a warez service
[01:00:10] <funkywizard> the http uploading is not something likely to generate a lot of controversy so we can host that wherever
[01:00:12] <`Shadow`> easynews / giganews have "legitimate" uses
[01:00:24] <backz> do you know about EventID 4226 from lvllord.de? I'm a linux user, can I set this in linux ?
[01:00:25] <The_8472> antigua, they got a limited copyright exemption from the WTO :P
[01:00:28] <`Shadow`> yeah, but then you deal with doubling your bandwidth costs by transferring frmo one colo to another
[01:00:33] <`Shadow`> ugh
[01:00:34] <The_8472> backz, no need to
[01:00:35] <`Shadow`> b/w in the carribean sucks
[01:00:36] <`Shadow`> i know
[01:00:42] <`Shadow`> i'm the sysadmin for an online gambling site :p
[01:00:46] <The_8472> hahaha
[01:00:49] <`Shadow`> you don't want to host anything requiring b/w down there
[01:00:50] <funkywizard> lol
[01:00:55] <funkywizard> i see
[01:01:07] <`Shadow`> some guy in our colo (curacao) got ddosed and it even affected internet in our office in costa rica ;P
[01:01:13] <`Shadow`> different country, same fiber ring
[01:01:18] <funkywizard> damn
[01:01:26] <funkywizard> FDC would be good performance wise
[01:01:27] <The_8472> sucky infrastructure then :/
[01:01:34] <funkywizard> they've improved their network a lot and its cheap
[01:01:38] <funkywizard> we're also familiar with the people there
[01:01:40] <The_8472> if you need bandwidth... get a port at AMS-IX ^^
[01:01:56] <backz> The_8472: my provider do Traffic Shaping, on Windows I can fuck this using EventID 4226 from lvllord.de and uTorrent. On Linux I'm using delugue and I can't reach the same speed.
[01:02:18] <The_8472> backz, this has NOTHING to do with 4226
[01:03:38] <The_8472> more likely that you ran into the deluge bug
[01:03:44] <The_8472> the encryption settings are flipped
[01:03:54] <The_8472> at least that's what i've heard
[01:06:41] <backz> The_8472: 4226 enables more connections on my torrents, if my provider changes the bandwidth of each connection I create more
[01:06:55] <`Shadow`> backz: then just increase the # of connections in your client
[01:07:03] <`Shadow`> 4226 is a windows issue, not a linux one
[01:07:13] <`Shadow`> if you need more connectiosn in linux, you have to increase the # of open files that are allowed
[01:07:28] <`Shadow`> do "ulimit -n" to see your current setting
[01:07:38] <The_8472> and 4226 does not increase the number of connections either
[01:07:39] <The_8472> not at all
[01:07:51] <The_8472> it just increases the number of connections you can start concurrently
[01:08:05] <The_8472> the overall number of connections you can have is not bounded by 4226
[01:12:32] <kjetilho> so 4226 is a hack to lift the XP/Vista Home limits?
[01:12:41] <`Shadow`> no
[01:12:54] <The_8472> 4226 is the event that occurs when you run into the limit
[01:13:03] <The_8472> lvllord is the patch to hack it
[01:13:13] <The_8472> for XP, not sure about vista
[01:13:35] <kjetilho> ok, thanks for the info
[01:14:24] *** backz has quit IRC
[01:27:37] *** [diablo] has quit IRC
[01:41:14] *** jlouis has joined #bittorrent
[01:53:18] *** Mitchman has quit IRC
[01:53:50] *** Mitchman has joined #bittorrent
[01:55:45] *** jlouis_ has quit IRC
[01:57:46] *** josch has joined #bittorrent
[01:58:07] <josch> can anyone help me finding a reference implementation of: http://www.bittornado.com/docs/webseed-spec.txt
[01:58:16] <josch> is webseeding used anywhere?
[01:58:43] <DeHackEd> how about the same site you found the document?
[02:00:24] <josch> then I may be too dump to find anything but I cannot find an implementation in php, perl or anything - I also never saw a webseed. are they alive or only a never used feature?
[02:02:07] <DeHackEd> oh god there's no peace around here... so much for that idea.
[02:02:10] *** [diablo] has joined #bittorrent
[02:06:45] *** Taube is now known as taube
[02:07:53] *** `Shadow` has quit IRC
[02:07:58] *** init0_ has joined #bittorrent
[02:12:41] <The_8472> the Az Inc guys use webseeding afaik
[02:12:53] <The_8472> i think it's the getright spec with pipelining though
[02:14:08] *** lioux has quit IRC
[02:19:39] *** init0 has quit IRC
[02:23:33] *** swinokur has quit IRC
[02:27:04] <josch> this http://en.wikipedia.org/wiki/BitTorrent_client shows that webseeding with the getright method is only supported by getright and azuerus so I assume that it's better to use the bittornado approach
[02:27:32] <josch> I also found my implementation: http://e.scarywater.net/bt/download/webseed-0.9a.zip
[02:27:41] <josch> but now website for it
[02:27:42] <DeHackEd> they mirror it?
[02:28:36] <josch> s/now/no/
[02:31:48] <The_8472> µT will support getright too in 1.8 afaik
[02:31:51] <The_8472> 2 major clients then
[02:41:18] *** [diablo] has quit IRC
[02:43:33] <alus> hah, that page has two Notes for the same thing
[02:44:42] <The_8472> someone probably cooked some copypasta
[02:49:28] *** camrdale has quit IRC
[03:03:19] *** nocturnal has joined #bittorrent
[03:03:35] <nocturnal> what is the purpose of announce-list being a tiered list?
[03:04:06] <nocturnal> so far i've only run into torrents that had one url, and i wonder why they must have it in a multi-dimensional list
[03:04:31] <nocturnal> one url in each list item of announce-list that is, because it's like ->[0]->[0]
[03:04:45] <ShadowJK> Tracker groups
[03:04:46] <nocturnal> but some have just a single dimensional list, i guess that's against the 'spec'
[03:04:56] <nocturnal> oh
[03:05:06] <nocturnal> i gotta look that up, is that like load balancing?
[03:05:11] <nocturnal> multiple ips
[03:05:22] <ShadowJK> Imagine you have 5 trackers, 3 of them share information, 2 don't, so you'd want to announce to 3 trackers
[03:05:27] <ShadowJK> erm
[03:05:46] <ShadowJK> Because the 3 have the same information, but the 2 other don't
[03:05:47] <nocturnal> but what do the ones that don't share information do?
[03:06:32] <ShadowJK> you can consider them as independent trackers that happen to be tracking the same content but not the same peers..
[03:06:33] <uau> it's a two-dimensional list to allow both load balancing and fallback
[03:06:36] <nocturnal> i'm guessing this is for much bigger trackers than i have run into so far, thank you very much for your information ShadowJK, i was just curious
[03:07:16] <uau> each level of trackers is for load balancing
[03:07:29] <uau> with the goal and each of the trackers gets an equal share of the load
[03:07:40] <nocturnal> when i first ran into announce-list i figured it in itself was for load balancing and fallback but i guess that's a nice EXTRA feature to allow it for each tracker, so you can seperate them easier
[03:07:51] <uau> and different levels are for fallback, using the later levels only if the earlier ones fail
[03:07:51] <DWKnight> http://wiki.depthstrike.com/index.php/P2P:Protocol:Specifications:Multitracker I believe may help you understand
[03:08:33] <uau> load balancing and fallback have different requirements and a single list couldn't fill them
[03:08:39] <DWKnight> truth
[03:09:03] <uau> for load balancing you want each client to pick a random tracker from those sharing the load
[03:09:09] <nocturnal> yeah i think i was confused about bittorrent there, i thought the whole announce-list was for fallback but it's a feature of bittorrent to allow multiple trackers
[03:09:25] <nocturnal> so in that feature you need another one for fallback
[03:09:30] <uau> but for fallback you want clients to not use the fallback trackers while the main tracker works
[03:09:42] <nocturnal> ok i understand now
[03:09:43] <nocturnal> thank you
[03:10:17] <DWKnight> the load balancing that multitracker gives is more intelligent than most other options
[03:10:23] <The_8472> <uau> it's a two-dimensional list to allow both load balancing and fallback <- tell that to alus
[03:10:29] <nocturnal> it's a shame though that i'm still running into files with a ONE-dimensional list of urls, i'm forced now to write my tracker code to handle those files
[03:10:58] <The_8472> nocturnal, your tracker does not have to handle any .torrent files at all
[03:11:03] <The_8472> trackers just track hash values
[03:11:17] <DWKnight> because it lets the "stronger" tracker catch what the "weaker" tracker can't handle
[03:12:10] <nocturnal> The_8472: yes i guess that's an option but i'm a newbie here and i'm just writing this for personal use, so this is as far as my knowledge gets me today
[03:13:11] <DWKnight> I wrote my uploader scripts to strip announce-list and then I have a different script rewrite it at download time
[03:13:22] <nocturnal> i'm doing that to
[03:13:32] <nocturnal> actually i'm rewriting the bdata at upload
[03:13:41] <nocturnal> so the downloader gets a proper file with announce-list
[03:14:01] <nocturnal> thanks, cya guys
[03:14:01] *** nocturnal has left #bittorrent
[03:14:05] <DWKnight> ..
[03:14:10] <DWKnight> I was going to say something
[03:14:13] <DWKnight> but oh well
[03:42:14] *** camrdale has joined #bittorrent
[03:42:46] *** slipstream-- has joined #bittorrent
[03:55:05] *** slipstream has quit IRC
[04:41:31] <alus> The_8472: you mean tell that to ludde!
[04:41:44] <alus> The_8472: I already did it once (with uau's help. thanks uau)
[04:43:51] <The_8472> well, alus is the new ludde :P
[04:47:58] *** GoussX has quit IRC
[04:51:11] *** The_8472 has quit IRC
[04:55:54] *** TheSHAD0W has quit IRC
[04:58:47] *** TheSHAD0W has joined #bittorrent
[05:33:07] <alus> The_8472: except without the potential buy-out :(
[05:33:33] *** ProperNoun has quit IRC
[05:36:56] *** GoussX has joined #bittorrent
[06:06:28] *** rcjsuen has quit IRC
[07:13:46] *** danomac has quit IRC
[07:40:37] *** MassaRoddel has quit IRC
[07:43:29] *** swinokur has joined #bittorrent
[08:19:31] *** camrdale has quit IRC
[08:55:05] *** danomac has joined #bittorrent
[10:01:51] *** [diablo] has joined #bittorrent
[10:12:35] <[diablo]> good morning #bittorrent
[10:13:15] <[diablo]> guys, as I'm still a newbie to BT, but understand clearly now the network setup, my only remaining question is regarding share ratios....
[10:14:15] <[diablo]> who (if anyone) of the likes of PBay etc,  monitors your share ratio... for example, I've downloaded 6gb, and upped atm 4,8gb
[10:15:03] <[diablo]> now if I did stop seeding right now, and did not continue the seed, does this have any adverse effects in anyway, besides that other people loose a seed?
[10:22:34] <uau> probably not
[10:24:39] <uau> a tracker can see what kind of ratios you report, but if it's not a ratio tracker it probably doesn't care
[10:25:18] <[diablo]> hi uau
[10:25:22] <uau> in principle any peer can keep a record of how much you've uploaded/downloaded to that specific peer (at least as long as it can identify you based on the same ip address or something else)
[10:25:25] <[diablo]> uau, ok,  understand
[10:25:41] <uau> but usually peers only care about shorter-term behavior
[10:25:59] <[diablo]> but its common courtesy to at least go 1.0
[10:26:33] <[diablo]> like atm, im letting it seed at 32KiB/s
[10:26:46] <[diablo]> then at 1.00, I'll stop
[10:29:40] <[diablo]> it's just a shame out here in Spain our up rate is so lame
[10:47:22] *** MassaRoddel has joined #bittorrent
[12:09:44] *** EvolutionCrazy has quit IRC
[12:09:59] *** EvolutionCrazy has joined #bittorrent
[12:23:36] *** josch has quit IRC
[12:32:34] <MassaRoddel> some1 knows what is now necessary to make changes here?: http://en.wikipedia.org/wiki/BitTorrent_client
[12:33:23] <MassaRoddel> i got: ..did not appear to be constructive and has been reverted or removed
[12:40:04] <MassaRoddel> nm, found it
[13:12:53] *** jlouis_ has joined #bittorrent
[13:26:34] *** jlouis has quit IRC
[13:35:40] *** MassaRoddel has quit IRC
[13:41:24] *** rcjsuen has joined #bittorrent
[14:04:51] *** MassaRoddel has joined #bittorrent
[14:45:30] *** Elperion has joined #bittorrent
[15:00:40] *** [diablo] has quit IRC
[15:09:06] *** lioux has joined #bittorrent
[15:21:51] *** Elperion has quit IRC
[15:55:09] *** taube is now known as Taube
[16:00:39] *** EvolutionCrazy has quit IRC
[16:02:35] *** EvolutionCrazy has joined #bittorrent
[16:10:57] *** thewird has quit IRC
[16:16:55] *** thewird has joined #bittorrent
[16:21:17] *** thewird has quit IRC
[16:21:47] *** thewird has joined #bittorrent
[16:58:44] *** Taube is now known as taube
[17:12:01] *** filix has joined #bittorrent
[17:12:19] *** filix has left #bittorrent
[17:17:52] *** DeHackEd has quit IRC
[17:22:02] *** DeHackEd has joined #bittorrent
[17:23:17] *** fireba11 has quit IRC
[17:39:13] *** [diablo] has joined #bittorrent
[17:39:15] *** EvolutionCrazy has quit IRC
[17:42:47] *** EvolutionCrazy has joined #bittorrent
[17:52:19] *** [diablo] has quit IRC
[18:44:46] *** danomac has quit IRC
[19:01:29] *** EvolutionCrazy has quit IRC
[19:01:40] *** EvolutionCrazy has joined #bittorrent
[19:15:56] *** spopp has joined #bittorrent
[19:19:12] *** rcjsuen_ has joined #bittorrent
[19:19:16] *** rcjsuen has quit IRC
[19:32:56] *** spoop has quit IRC
[19:43:42] *** MyName has joined #bittorrent
[19:43:48] <MyName> is it true that blueray won?
[19:44:08] <TheSHAD0W> Likely, IMO.
[19:44:20] <MyName> why
[19:44:25] <thewird> i blame the PS3
[19:44:35] <MyName> what about microsoft?
[19:44:40] <thewird> also blueray sounds cooler
[19:44:49] <TheSHAD0W> Major movie theaters stopped making HD-DVDs...
[19:44:50] <MyName> have u seen a bluray video disc
[19:44:59] <kjetilho> if Microsoft truly cared about HD-DVD, they would sink the cost and make it a standard feature of the Xbox 360
[19:45:03] <TheSHAD0W> Sony's licensed the tech to other companies, so it's not a monopoly...
[19:45:12] <TheSHAD0W> And yeah, they got it into the market w/ the PS3.
[19:45:26] <thewird> BlueRay vs HD-DVD
[19:45:27] <TheSHAD0W> Microsoft doesn't really care about the HD-DVD.
[19:45:35] <thewird> i think we are all tired of hearing HD this and HD that
[19:45:45] <thewird> BlueRay is something new
[19:45:46] <TheSHAD0W> http://cgi.fark.com/cgi/fark/youtube.pl?IDLink=3307880
[19:45:58] <kjetilho> plus Bluray is technologically superiour
[19:46:25] <thewird> yah it has a lot more potential
[19:46:28] <kjetilho> 100 GB Bluray (quad layer) will be available pretty soon
[19:47:04] *** DWKnight has quit IRC
[19:51:17] *** [diablo] has joined #bittorrent
[20:07:33] *** slipstream-- has quit IRC
[20:11:43] *** slipstream has joined #bittorrent
[20:16:56] *** cosmodad has joined #bittorrent
[20:25:14] *** danomac has joined #bittorrent
[21:02:38] *** ProperNoun has joined #bittorrent
[21:39:21] *** camrdale has joined #bittorrent
[22:10:49] *** MyName has quit IRC
[22:20:53] *** thewird has quit IRC
[22:21:20] *** thewird has joined #bittorrent
[22:21:53] *** thewird has joined #bittorrent
[22:22:42] *** spoop has joined #bittorrent
[22:28:14] *** rcjsuen_ is now known as rcjsuen
[22:37:34] *** spopp has quit IRC
[23:27:03] *** cosmodad has quit IRC

top