[00:01:32] <BentMyWookie> http://torrentfreak.com/five-bittorrent-predictions-for-2010-100101/
[00:01:41] <BentMyWookie> seems like crap predictions to me
[00:06:38] <TheSHAD0W> 1. Unlikely.  3. Unlikely without a whole new standard.  2, 4. Maybe.  5. Already true.  :-P
[00:07:07] <BentMyWookie> heh
[00:08:25] <chelz> i had thought of TPB removing torrents a little while ago. good to see it getting some press.
[00:08:35] <TheSHAD0W> Well.
[00:09:01] <TheSHAD0W> IMO there's no legal difference between a magnet link and a torrent file.
[00:09:40] <TheSHAD0W> Now, if they made it so it was just a magnet URL, which had to be copied and pasted into the client, that would be a small legal difference.
[00:09:43] <chelz> only until it's brought before a court will there be a decision. but one difference i see is that google "links" to things but "hosts" nothing.
[00:10:01] <chelz> yeah but it's still the matter of "hosting" anything at all, since tpb "hosts" .torrent files
[00:10:22] <TheSHAD0W> A torrent file isn't hosted content, it's essentially just meta-information.
[00:10:33] <chelz> yeah, but legally there might be some wiggle-room
[00:10:34] <chelz> as silly as it all is, it's another chance to argue before a judge
[00:11:54] <chelz> i sure hope some p2p streaming thing comes out already. bram cohen working in secret on his isn't too encouraging.
[00:15:24] <The_8472> live streaming is fundamentally impossible if the aggregate upload bandwidth is smaller than the aggregate bandwidth required by all those who wish to stream.
[00:15:48] <The_8472> and iirc bram said something about a 99% offload ratio, i.e. basically <= 1% backing by a CDN
[00:17:08] <The_8472> and even when the aggregate upload bandwidth is sufficient you still have to give up some fairness...
[00:19:29] <chelz> what's the result of giving up fairness? peers on slower connections not getting.. something?
[00:20:32] <The_8472> no, the opposite
[00:20:58] <The_8472> you give up fairness to allow slower peers to stream too. which means faster peers get less than they could under the current model
[00:24:39] <chelz> ah
[00:26:31] <chelz> well eztv's method of having a bunch of volunteers with really fast connections getting items to be shared first is somewhat like a CDN. preference to the 'CDN peers' could be built into the protocol.
[00:31:25] <The_8472> that's a horrible idea if thousands would flock to a handful of seeds
[00:32:29] <chelz> well initially. better to have a handful of seeds than just one.
[00:33:06] <chelz> or unless there's another solution i'm missing
[00:37:03] <alus> chelz: uTorrent has p2p streaming in the latest alpha
[00:37:48] <chelz> alus: oh cool. is it based on anything bram is working on? and if it works out will it become a bep?
[00:38:28] <alus> my predictions on the predictions: 1. Yes (and please!) 2. Doubt it 3. What? No. 4. Not live, just streaming. 5. Haha. Not true or likely
[00:38:41] <alus> TheSHAD0W: uTorrent is a resource hog? by what metric?
[00:38:52] <TheSHAD0W> I was kidding.
[00:38:57] <alus> chelz: Bram is working on live streaming, which is not BitTorrent based, which is nowhere near ready
[00:39:05] <alus> TheSHAD0W: oic
[00:39:37] <alus> chelz: the streaming protocol in uTorrent is not likely to be BEP'd, sadly. it doesn't require any protocol changes
[00:40:10] <The_8472> <alus> chelz: Bram is working on live streaming, which is not BitTorrent based, which is nowhere near ready <- good news!
[00:40:19] <chelz> hah
[00:40:50] <The_8472> alus, so you're potentially going to hurt swarms and all we have is "don't worry, we know what we're doing"? because that's all i've seen so far
[00:41:10] <chelz> alus: i'm sure you've heard of that Swarmplayer stuff that even eztv picked up on, is utorrent's clearly better or different?
[00:48:52] <alus> chelz: I have not read Tribler's implementation, but when we talked with the developers we were not as impressed with their approach
[00:49:04] <The_8472> it's always a dilemma... either i get to say "i told you so" and watch things falling apart or i was wrong but everything works fine.
[00:49:56] <alus> The_8472: that's true of our choker, and other details in uTorrent as well. sorry, that's just how closed source clients work. clearly if we hurt swarms it's going to hurt us too, so that wouldn't be in our interest
[00:51:20] <alus> The_8472: but, giving away details of a feature we've put a lot of time in is not something we can do easily (see: shareholder oblications) since it might fuel competition (see: Tribler)
[00:51:51] <alus> The_8472: if you think you can contribute to the feature in a positive way, we would probably be happy to pay you for that (see: employment)
[00:52:00] <The_8472> i'm not asking how your streaming works. i'm only interested in what safety measures/constraints you have put onto it.
[00:52:55] <alus> the largest safety measurement is that few people will use it. the next is that if lots of people do use it, then it's clearly in high demand. if the swarm can't keep up, then it can't keep up with demand
[00:53:17] <alus> if you're asking about how it will gracefully degrade in that case I think that's an interesting issue, but nearly an edge case
[00:54:46] <The_8472> well, even if it works at some particular moment it's possible that it'll shorten the torrent's lifecycle and thus have an impact on those who start the torrent later
[00:54:55] <The_8472> i.e. you're offloading the damage into the future
[00:55:14] <The_8472> reminds me a lot of environmental problems ^^
[00:55:22] <The_8472> "see it works, thus it cannot be bad"
[00:55:38] *** jordy240 has joined #bittorrent
[00:55:57] *** jordy240 has left #bittorrent
[00:56:40] <chelz> would a system not work if there was a separate 'streaming torrent file' for people to get if they want to stream and be part of a separate swarm?
[00:56:48] <alus> it does put more load on the swarm than not. however, it also extracts more value. I think users prefer this
[00:56:58] <chelz> i guess it would be slower for streaming users but it wouldn't degrade the performance of the original swarm
[00:56:59] <The_8472> my favorite scenario in this case: there is a VERY fast initial seeder (think seedboxes), people can stream from that. now you have 30 people with a progress of 80% each. in sequential downloading. all of them streamed from the seed. that makes 24 times the file uploaded from the seed, but still most pieces concentrated around the first 80%
[00:57:00] <The_8472> now the seed departs
[00:57:03] <The_8472> boom!
[00:57:08] <The_8472> and you get bad swarm performance
[00:57:14] <alus> chelz: it would not work. there would not be enough users any time soon, and that would keep it from growing
[00:57:45] <alus> The_8472: that means no one had download bandwidth in excess of the video bitrate, too
[00:58:29] <The_8472> even if they have download bandwidth in excess of the video bitrate it would still introduce a very heavy skew that'll make the torrent rather unhealthy after the departure of the initial seed. and it'll make seeding less efficient
[00:58:29] <alus> or stopped watching at some point. or started watching a little after starting the torrent
[00:58:51] <alus> The_8472: heavy skew, but not dead. the torrent would fix itself rather quickly
[00:58:53] <The_8472> basically forcing people to superseed to avoid those streamers wasting your bandwidth
[00:59:25] <The_8472> <alus> it does put more load on the swarm than not. however, it also extracts more value. I think users prefer this <- only the users who are streaming. at the cost of everyone else.
[00:59:42] <alus> would you prefer 30 people never joined the torrent?
[00:59:56] <alus> then the initial seeder goes away, and there are 0 copies of any piece
[01:00:08] <alus> we think streaming will make BitTorrent more popular
[01:00:09] <The_8472> i would prefer if they'd just use rarest first and watch later, like they do now
[01:00:44] <alus> users don't like that as much
[01:01:02] <The_8472> people also like to drive fuel-guzzeling cars. doesn't mean they actually should
[01:01:19] <The_8472> what people like != what's good from the big perspective
[01:01:39] <The_8472> people like to hit&run and not upload on torrents too
[01:01:47] <The_8472> does that mean we should build that as a feature into clients?
[01:02:01] <alus> obviously we are going to not make it do that
[01:02:17] <alus> but we will support a transport which solves the motivation behind why users want that - latency
[01:02:18] <The_8472> yes, of course i'm making exaggerated examples here
[01:03:28] <The_8472> i still think that streaming will have a negative impact for at least some users
[01:03:50] <The_8472> e.g. shortening a torrent's lifecycle and thus preventing latecomers from downloading it
[01:04:08] <The_8472> or making it less efficient overall when too many people start streaming
[01:05:12] <The_8472> i do agree that it'll most likely have close to 0 impact if only a few people do it on a big, wellseeded torrent or whatever... but that's not what i'm concerned about
[01:05:19] <The_8472> i'm concerned about the edge cases
[01:05:38] <The_8472> where streaming could substantially hurt the swarm and thus should be disabled
[01:10:33] <chelz> looking over the features of uTorrent 2.1 beta i see certain very nice things. the speed test to figure out where to cap upload in the setup wizard and the transfer cap in settings are both very cool.
[01:11:24] <alus> I wish everyone would implement uTP so we wouldn't need the speed test
[01:11:48] <chelz> that would be nifty. getting other clients to integrate it aswell.
[01:12:05] <chelz> oh wow integrated use of DNA, i was wondering why my upload was being maxed. that's kinda dirty and sketchy ;/
[01:13:18] <alus> it's highly unlikely DNA is actually in use for you
[01:13:28] <alus> if it was, you would see a DNA torrent in the UI
[01:13:30] <alus> do you?
[01:13:54] <alus> (category view would have a DNA section, it would contain one or more torrents)
[01:14:29] <chelz> oh my mistake, i was misreading the bottom bar.
[01:14:42] <alus> it's really not meant to be dirty or sketchy. it's very up-front and visible. it's basically just a new API for adding torrents
[01:16:01] <chelz> i figured it was like that but when i saw it enabled and thought my upload was being used i assumed i was being used as an automatic node in some CDN network. good to hear that's not the case.
[01:16:03] 
[01:16:18] <The_8472> or with tiered networks, like fast local and slow international speeds
[01:16:44] <alus> how is it causing problems?
[01:17:07] <The_8472> slowing down tcp connections too much so that the line is actually underutilized for example
[01:17:10] <chelz> well i think a fear about the streaming issue is not that uTorrent itself would make it popular but that it will popularize the idea, instead of a mostly unanimous view now after the failure of the Swamplayer that torrent streaming doesn't work.
[01:17:25] <alus> chelz: it also will certainly not participate in any swarms you are not watching/using a file from.
[01:17:48] <chelz>  people could go "well uTorrent is doing it, so it must be a somewhat proven technolgy", then clients dedicated to just streaming stuff, not to be used as a normal torrent client might come out
[01:17:50] <alus> The_8472: that's not uTP's problem. that's the rate balancer we hooked TCP and uTP together with. it's being conservative
[01:18:04] <The_8472> i see
[01:18:49] <alus> as more uTP connections are available, that will get more and more accurate
[01:18:59] <The_8472> chelz, i can imagine even worse reasoning... "if streaming is fine, we can just do sequential piece picking."
[01:19:00] <alus> which is why everyone should implement it >.>
[01:19:19] <The_8472> did i mention that it's tackling the problem at the wrong layer? ^^
[01:19:33] <alus> you did, except it's the right layer
[01:20:15] <The_8472> well, it would be futile to rehash all the arguments again.
[01:20:24] <alus> feel free to implement it in AZ with UDP, or in Windows as a network-stack driver modification to TCP. whichever you think is easier
[01:20:45] <The_8472> i would prefer the latter, but i lack the knowledge to do so
[01:21:00] <alus> so does like everyone on the planet. and if you get it wrong, you get a bluescreen
[01:21:14] <The_8472> nah, you could run most of the code in userspace
[01:21:22] <The_8472> even gfx drivers run in userspace now
[01:21:26] <alus> again; feel free
[01:22:11] <The_8472> <alus> so does like everyone on the planet. <- except people who area already doing driver programming for windows maybe? those who know their ways through the APIs?
[01:23:28] 
[01:28:59] <alus> The_8472: there are only about 10 of those people who are any good, and all the hardware manufacturers are paying them a whole lot of money to keep the significant investment in manufacturing from being a complete waste
[01:29:41] <alus> so yeah, I could give up P2P, buckle down and learn the insides of Windows without any source code, and probably be paid better
[01:29:45] <alus> boring and painful, however
[01:32:14] <The_8472> well, it's not really my area so i know even less about it than you do. but i would have assumed that there should be more people with enough knowledge to do it. i mean the algorithms themselves aren't that hard. tcp has timestamping too... so it's mostly knowing your way through the innards of windows.
[01:32:39] <The_8472> it pains me greatly to see people reinventing TCP over and over just to change one element here or there
[01:49:45] *** bit1 has joined #bittorrent
[01:49:50] <bit1> Hot new site : Torrentpirates.org
[01:49:58] *** bit1 has quit IRC
[02:04:57] <chelz> speaking of hot new sites
[02:05:00] <chelz> uriel: have you seen http://btreannouncer.net/ ?
[02:07:52] <alus> The_8472: the goal is not to re-invent TCP. the goal is to prove a congestion controller which should be an option for TCP. implementing TCP over UDP is the easiest way to do that
[02:08:15] <alus> The_8472: once it's proven, we hope OSes will start to implement support for it
[02:09:17] <The_8472> well, that's what i meant. people basically do their own UDP transports just to reimplement 90% of TCP again and change the reamaining 10%
[02:11:00] <The_8472> i guess what i'm really complaining about is that TCP stacks are not modular enough
[02:12:20] <The_8472> retransmission: off, flow control: new FlowController();, reordering: off, PMTU detection: on, ...
[02:12:29] <The_8472> code reuse!
[02:27:11] <burris> I'm looking forward to better progressive dl in uT, the current version is annoying (dl in piece instead of lexigraphic order, no endgame mode, etc...)
[02:27:38] <burris> also not easy to turn on/off so I leave it on all the time
[02:28:31] * The_8472 glares at burris
[02:35:00] <burris> there were half a dozen pepole live streaming the phish concert last night from their phones, sucks that they devote so much space to useless video which could be devoted to higher quality audio...  I'm surprised nobody is 'casting from the taper section with high quality audio.
[02:36:30] <burris> they all seem to use the ustream service
[03:30:19] <alus> burris: you mean file progressive not streaming, right?
[03:31:13] <alus> streaming is single file only
[03:32:55] <alus> but yeah, file progressive could be a lot better
[03:58:19] *** Switeck has joined #bittorrent
[04:06:19] *** The_8472 has quit IRC
[04:08:25] *** The_8472 has joined #bittorrent
[04:13:38] *** kwinz2 has quit IRC
[04:14:13] <swolchok> re: DHT proposals, I really like the bootstrap notification, would make my life easier
[04:14:51] *** GTHK has left #bittorrent
[04:14:59] *** GTHK has joined #bittorrent
[04:16:01] <swolchok> "HI I WANT TO FREELOAD"
[04:16:16] *** kwinz2 has joined #bittorrent
[04:18:18] *** GTHK has quit IRC
[04:23:31] *** init0_ has quit IRC
[04:25:18] *** init0 has joined #bittorrent
[04:54:36] *** lioux has joined #bittorrent
[04:55:19] *** rrr_ has quit IRC
[04:55:58] *** GTHK has joined #bittorrent
[05:12:19] *** lioux has quit IRC
[06:00:16] *** lioux has joined #bittorrent
[06:25:01] *** norc__ has left #bittorrent
[06:48:48] *** MassaRoddel has quit IRC
[07:28:16] *** goussx_ has joined #bittorrent
[07:35:43] *** goussx has quit IRC
[07:35:43] *** goussx_ is now known as goussx
[08:17:11] *** GTHK has quit IRC
[08:22:25] *** kwinz2 has quit IRC
[08:23:50] *** kwinz2 has joined #bittorrent
[08:32:19] *** Switeck has quit IRC
[08:37:25] *** GTHK has joined #bittorrent
[09:04:47] *** MassaRoddel has joined #bittorrent
[09:15:41] <chelz> hey so i just had an idea
[09:16:25] <chelz> i think i found a way to cheat extremely cleanly on private tracker sites. please tell me if this is a known issue.
[09:16:36] <chelz> doing a single announce to the tracker then not connecting to it at all further. peers would then upload to you like any other user.
[09:16:37] <chelz> then when you're done you can start seeding it and get real upload credit
[09:16:52] *** GTHK has quit IRC
[09:17:05] <chelz> the key is making sure download never gets reported to the tracker
[09:17:14] <chelz> the only discrepancy the admin of the private tracker would see is that there's a difference in the reported aggregate upload vs download, but i don't know how they'd find out what peers/users are responsible
[09:20:57] <chelz> is this old news?
[09:22:10] <andar> cheating trackers? it's always been pretty easy, hasn't it?
[09:22:31] <chelz> i mean i guess so if what i described works
[09:22:36] <chelz> i had no idea *how* easy though
[09:23:34] <chelz> is there any place out there with examples of the bittorrent protocol? for example, what exactly is sent back and forth during an announce
[09:23:50] <andar> chelz: bep 3
[09:24:00] <andar> www.bittorrent.org
[09:24:02] <chelz> andar: many thanks :)
[09:24:04] <chelz> yeah
[10:17:41] *** echelog has joined #bittorrent
[11:21:32] *** MassaRoddel has quit IRC
[11:26:34] *** bt42 has joined #BitTorrent
[11:47:34] *** bittwist has quit IRC
[12:39:21] *** kwinz2 has joined #bittorrent
[12:39:50] *** ivan` has quit IRC
[12:40:00] *** ivan` has joined #bittorrent
[13:14:05] *** MassaRoddel has joined #bittorrent
[13:40:22] *** choykloun has quit IRC
[16:18:58] *** bittwist has joined #BitTorrent
[16:29:14] *** Waldorf has joined #bittorrent
[16:33:03] *** Waldorf has quit IRC
[16:37:21] *** bt42 has quit IRC
[16:45:59] *** _rafi2_ has joined #bittorrent
[17:03:38] *** _rafi_ has quit IRC
[17:05:44] *** Gottaname has quit IRC
[17:07:46] *** Gottaname has joined #bittorrent
[18:18:49] *** PN has quit IRC
[19:38:30] <BentMyWookie> anyone know what client -OS0690- is?
[19:44:16] <DWKnight> "OneSwarm"
[19:46:14] <BentMyWookie> thanks
[19:54:59] <TheSHAD0W> One swarm to rule them all
[19:55:04] <TheSHAD0W> One swarm to BIND them
[19:55:10] <TheSHAD0W> One swarm to download them all
[19:55:40] <TheSHAD0W> And in the intertubes...
[19:55:45] <TheSHAD0W> Man, screwed them up.
[20:06:23] *** GTHK has joined #bittorrent
[22:10:22] <TheSHAD0W> http://epicwinftw.com/2009/12/30/mazda-pi/
[22:11:26] *** _rafi2_ has quit IRC
[22:28:00] *** _rafi_ has joined #bittorrent
[22:51:57] *** Smushers has joined #bittorrent
[23:21:02] *** _rafi_ has quit IRC
[23:30:46] *** lioux_ has joined #bittorrent
[23:36:10] *** lioux has quit IRC
[23:43:07] *** medecau has joined #bittorrent
[23:46:02] *** Waldorf has joined #bittorrent
[23:54:08] *** Smushers has quit IRC





top