[00:00:24] <Switeck> uTP actually has serious issues right now, at least for a few people.
[00:00:49] <WhatMan> Routers exploding?
[00:00:53] <Switeck> usually setting bt.tcp_rate_control to false helps well enough.
[00:00:56] <Switeck> oh that also. :P
[00:01:23] <WhatMan> It already represents a third of our peers, so it can't be that bad.
[00:01:56] <IRConan> WhatMan speaks!
[00:01:58] <IRConan> how goes it?
[00:02:02] <WhatMan> The users would be yelling a lot louder if things were properly broken.
[00:02:17] <WhatMan> It's going alright, IRConan. Going to make some users angry tonight though. You?
[00:02:18] <Switeck> People on private trackers using Vuze already could use a plugin to block certain BT clients, or use its own UDP mode.
[00:02:34] <Switeck> WhatMan, i doubt they know
[00:02:56] <WhatMan> Hm. What are the serious issues, and how serious are they?
[00:03:01] <Switeck> If you're already having trouble seeding, it's hard to separate uTP issues out.
[00:03:02] <IRConan> WhatMan: pretty good... have you seen http://tracker.irconan.co.uk ? It's running ocelot, pending one more known bug it's on the the "new features"
[00:03:41] <Switeck> The serious issues are speeds can drop to 0 for no apparent reason.
[00:04:00] <Switeck> peers/seeds trying to use uTP can fail to connect or rather stay connected for no apparent reason.
[00:04:12] <WhatMan> I love "no apparent reason" issues.
[00:04:46] <WhatMan> I haven't, IRConan. Checking it out now though.
[00:04:55] <Switeck> It's program bugs.
[00:05:21] <Switeck> but not JUST program bugs, some of this can be caused by "routers exploding" or crap software firewalls.
[00:05:28] <IRConan> WhatMan: I just realised reg is open? can you tell me how to close it?
[00:05:46] <WhatMan> IRConan: config.php
[00:06:04] <WhatMan> define('DEBUG_MODE',false); //Set to false if you dont want everyone to see debug information, can be
[00:06:44] <IRConan> WhatMan: I've got that set false...
[00:06:57] <WhatMan> Then it sounds like something is broken somewhere.
[00:07:08] <IRConan> ahah... open reg is just below it
[00:07:21] <WhatMan> Oh, oops. I totally copied the wrong line.
[00:07:26] <IRConan> ha
[00:07:27] <WhatMan> My bad.
[00:07:37] <IRConan> i wondered if it was a difference between RC1 and now
[00:07:55] *** Andrius has quit IRC
[00:08:27] *** burris has joined #bittorrent
[00:12:51] <semaphore> hi
[00:13:37] <semaphore> can someone tell me the difference between torrent_pass and torrent_pass_secret in xbt?
[00:14:04] <IRConan> afaik torrent_pass_secret is useless...
[00:14:08] <IRConan> I know we don't use it
[00:14:33] <semaphore> torrent_pass foo.net/[torrent_pass]/announce right?
[00:14:41] <IRConan> yeah
[00:14:44] <semaphore> i can't determine where the other is used,
[00:15:29] <The_8472> maybe the serverside key used to generate it?
[00:15:37] <DWKnight> this is why I don't like olaf's stuff
[00:15:44] <semaphore> hard to follow?
[00:15:48] <DWKnight> he doesn't document
[00:16:01] <semaphore> it's hard to trace the sql to the code, too
[00:16:07] <The_8472> who needs documentation? code should be readable ^^
[00:16:22] <IRConan> hence we're replacing it
[00:16:28] <semaphore> i didn't follow how other trackers i looked at could be replicated across a wan
[00:16:43] <semaphore> IRConan: do you run what.cd ?
[00:16:53] <IRConan> no... WhatMan does
[00:17:08] <semaphore> i suppose that would make sense
[00:17:22] <The_8472> semaphore, i think opentracker can be replicated over a wan
[00:17:22] <IRConan> I'm developing the tracker
[00:17:31] <The_8472> but i guess that's not what you need ^^
[00:17:48] <semaphore> not sure why i felt like i needed a sql backend
[00:19:46] <semaphore> IRConan: is it safe to assume that the one your crafting will have one?
[00:20:08] <IRConan> i'll be with you in a sec
[00:20:52] *** burris has quit IRC
[00:28:36] *** kwinz2 has joined #bittorrent
[00:57:33] *** andar2 has quit IRC
[01:07:41] <K`Tetch> http://torrentfreak.com/how-and-why-bittorrent-works-a-visualization-100217/
[01:07:45] <K`Tetch> nice visualisation
[01:15:10] * Nolar presses 's' and 'p' a couple hundred times
[01:15:39] <The_8472> makes a good browser JS engine test i guess ^^
[01:17:07] <Nolar> single threaded only :(
[01:17:14] <K`Tetch> yeah, i know
[01:33:32] <Switeck> The simulator doesn't do much for asymmetric speed estimations and jackass users I bet. :P
[01:34:21] <The_8472> or clustering
[01:34:35] <Switeck> How much skewing results from "islands" of peers that don't connect much/any with each other or sequential downloaders...is well worth study.
[01:34:50] <Switeck> Even firewalled peers/seeds really clobber the results.
[01:39:19] *** everthonVS has joined #bittorrent
[01:41:07] <K`Tetch> actually it does do asymetric speeds
[01:43:53] <Nolar> not sure it's worth more than looking really pretty :)
[01:44:52] *** everthonVS has quit IRC
[01:45:16] *** valadao has joined #bittorrent
[01:45:16] *** everthonVS has joined #bittorrent
[01:46:08] *** everthonVS has quit IRC
[01:46:51] <Switeck> but does it assume each peer/seed is about the same?
[01:47:34] <Switeck> A sudden arrival of 10 firewalled fast download, very low upload 0% done peers might be nasty. :(
[01:56:50] <IRConan> semaphore: sorry... that was rather longer than expected... what did you want to know? whether my tracker uses a SQL backend?
[01:57:15] <semaphore> yeah, maybe the two line marketing pitch? :)
[01:57:57] *** stalled has quit IRC
[01:58:09] <semaphore> c++? mysql? documented?  what shortcomings of xbt are you solving?
[01:58:10] <IRConan> heh
[01:58:14] <semaphore> just curious, really
[01:59:30] <IRConan> yes C++, all classes have documented interfaces, very configurable and theoretically extensible, all data is cached in RAM so you never have to wait for a SQL query to finish to complete an announce, write back is done asynchronously
[02:00:01] <semaphore> that sounds nice
[02:00:06] *** stalled has joined #bittorrent
[02:00:32] <semaphore> when will it be done?
[02:05:28] *** stalled has quit IRC
[02:05:54] *** burris has joined #bittorrent
[02:08:29] *** burris has quit IRC
[02:11:17] <IRConan> semaphore: "when it's done" isn't a good answer is it?
[02:12:21] <The_8472> it is if you work for blizzard
[02:12:33] *** stalled has joined #bittorrent
[02:12:54] <semaphore> IRConan: i know, i suppose a more answerable question is "is it started?" or "how's it going"
[02:13:38] <IRConan> yes it's started... it's "getting there", stats recorded are inaccurate because the code hasn't been tested and I think I made a typo somewhere
[02:14:02] <IRConan> I'm currently fixing the configuration and logging to make the future testing easier
[02:14:27] <semaphore> you said it will eventually be opened? is it mysql or more agnostic ?
[02:15:09] <IRConan> I was just thinking that while I was on the toilet... the SQL queries it uses are very simple and I don't see why I couldn't make it more agnostic (I'm not a big fan of the SQL library I'm using at the moment)
[02:15:16] <IRConan> at the moment it's just built using mysql++ though
[02:18:09] <semaphore> i'm a fan of postgres, was considering porting xbt to use it
[02:20:32] <IRConan> that was what made me think, a lot of people are in a "not sure about MySQL" state at the moment
[02:20:38] <IRConan> using a SQL abstraction layer would be much nicer
[02:21:11] <IRConan> I'll stick it on the long-term todo but I wouldn't expect it soon (since what is using MySQL, as are all gazelle sites since gazelle is built for it)
[02:21:54] <IRConan> WhatMan: ah... I see what you mean about making people unhappy. To be honest, "good call", vuze is utter shite
[02:22:06] <semaphore> is there a gazelle url?
[02:22:23] <IRConan> semaphore: I think it's down... lemme see
[02:22:38] <IRConan> ahah... http://85.17.87.6/
[02:22:49] <IRConan> (we seem to have lost the domain)
[02:23:12] <semaphore> gazelle is the user system/site for what.cd and other sites?
[02:24:36] <IRConan> yeah
[02:25:03] <IRConan> the code which is currently available is very old, they're in the process of releasing RC2
[02:26:58] *** neurodrone has quit IRC
[02:27:14] *** neurodrone has joined #bittorrent
[02:27:47] <semaphore> i'm more interested in this tracker.. that is the ocoelot portion?
[02:27:59] <IRConan> yeah
[02:28:35] <semaphore> well, i'll keep an eye out for it
[02:32:08] <IRConan> there are more planned features
[02:32:35] <IRConan> for example... a direct control interface, ie a socket you can open to the tracker and run "commands" like "add torrent", "add user", etc
[02:33:26] <semaphore> IRConan: instead of throwing the user or torrent into the database
[02:34:02] <IRConan> indeed, since that causes the tracker to have to poll the DB causing unec. load
[02:41:38] <semaphore> that's a good point. that would be cool
[02:52:46] <IRConan> semaphore: so... what do you think should be supported that's not in other trackers? I'm always open to more suggestions
[02:55:32] <semaphore> right now, i can't come up with anything... i guess i chose xbt for now since it could be manipulated by proding at its mysql backend
[02:56:24] <semaphore> and by doing so, could probably have mysql mater master replication with an xbt at each location
[02:56:28] *** valadao has quit IRC
[02:56:38] <semaphore> i guess the other trackers didn't seem to make that AS easy
[02:56:56] <IRConan> what kind of things do you want to be able to manipulate?
[02:57:27] <semaphore> well, add torrents is all the functionality i've implemented so far
[02:57:43] <IRConan> fair enough
[02:58:10] <semaphore> i see your point, though, after a certain point askign the db over and over if a user secret is valid is not going to fly
[02:59:00] <semaphore> that, and i haven't tried setting up that many trackers before deciding and going with one
[03:07:26] <alus> wow, 76k peers on this torrent
[03:08:44] <Nolar> nice
[03:19:24] <TheSHAD0W> *BELCH*
[03:22:03] <IRConan> semaphore: my plan is that as long as the link with the site is known to be active the tracker knows it never has to poll the DB
[03:59:27] *** Skeeve_KAM has joined #bittorrent
[04:01:12] *** edigaryev has joined #bittorrent
[04:01:14] *** The_8472 has quit IRC
[04:04:38] *** The_8472 has joined #bittorrent
[05:25:49] *** goussx has quit IRC
[05:32:17] *** neurodrone has quit IRC
[05:45:01] *** init0 has quit IRC
[05:47:02] *** init0 has joined #bittorrent
[05:51:45] *** edigaryev has quit IRC
[06:01:14] *** Skeeve_KAM has quit IRC
[06:28:12] *** Andrius has joined #bittorrent
[06:29:07] *** goussx has joined #bittorrent
[06:29:43] *** chrisbeebops has joined #bittorrent
[06:34:36] *** virus has joined #bittorrent
[06:38:38] *** Patchworks has joined #bittorrent
[06:40:21] *** Patchworks has left #bittorrent
[06:44:18] *** KyleK_ has joined #bittorrent
[06:50:05] *** KyleK_ has quit IRC
[06:51:55] *** chelz has joined #bittorrent
[07:37:02] *** _rafi_ has joined #bittorrent
[07:47:12] *** satz has joined #bittorrent
[07:53:39] *** GTHK has quit IRC
[07:53:57] *** senex has joined #bittorrent
[07:54:47] *** satz has left #bittorrent
[07:54:56] <Switeck> Did you do your part to stop the undead hordes?  http://www.theregister.co.uk/2010/02/17/spam_botnet_trends/
[08:46:19] <Andrius> yes, I don't use windows
[08:47:10] <Switeck> that's a simple solution XD
[08:47:35] <Switeck> hopefully, that also means no Adobe (Flash or PDF reader) products
[08:52:55] <Andrius> I try to avoid them, but it's not always possible
[08:55:28] *** burris has joined #bittorrent
[09:43:04] *** burris has quit IRC
[09:49:06] *** edigaryev has joined #bittorrent
[09:49:17] *** burris has joined #bittorrent
[09:54:58] *** _rafi_ has quit IRC
[10:08:40] *** chelz has quit IRC
[10:29:45] *** senex has quit IRC
[11:06:58] *** Balsaq has joined #bittorrent
[11:13:40] <burris> is it rude to seed a torrent from hotel wifi?
[11:14:15] <kjetilho> yes
[11:14:57] <Switeck> If you absolutely must, limit connections VERY low, disable stuff like DHT and local peer discovery...and lower upload and download speed to "barely broadband" levels.
[11:20:21] <burris> how many people getting hooked up with a fresh torrent does it take to offset one pissed off business traveler who can't check his porn?
[11:26:34] <kjetilho> use your seedbox instead
[11:33:25] *** andar has quit IRC
[11:33:39] <burris> don't have one, I'd still have to upload it anyway, why don't you start downloading it and seedbox for me because it might be a while before the guys on the east coast wake up and start downloading it
[11:33:47] <burris> :-)
[11:41:25] *** andar has joined #bittorrent
[12:29:22] *** KyleK_ has joined #bittorrent
[12:35:09] *** KyleK_ has quit IRC
[12:38:02] <Andrius> #bittorrent - your personal seedbox
[12:45:54] *** K`Tetch_ has joined #bittorrent
[12:47:37] *** K`Tetch has quit IRC
[13:40:11] *** n215 has quit IRC
[14:04:18] *** Gottaname has quit IRC
[14:12:22] *** Balsaq has quit IRC
[14:20:32] *** Gottaname has joined #bittorrent
[14:32:09] *** Gottaname has quit IRC
[14:48:48] *** flo_ has joined #bittorrent
[14:48:58] <flo_> hi
[14:49:14] <flo_> is it normal that i only get download rates about 20 kb/s ?
[14:49:40] <flo_> my client is telling me that i'm not uploading... but in my router i have opened the port :/
[14:51:54] <DWKnight> port being opened or not has nothing to do with not uploading
[14:52:09] <flo_> yeah. but port not opened means no upload, right?
[14:52:13] <DWKnight> wrong
[14:52:14] <DWKnight> http://bt.degreez.net/firewalled.html
[14:53:43] <flo_> oh, thank you
[14:54:07] <flo_> so, are those transfer rates normal? or does it mean that i did something wrong?
[14:54:31] <DWKnight> could be something as simple as a slow swarm
[14:55:23] <DWKnight> there are far too many factors to look at for me to be able to give you an answer without more info
[14:55:38] <flo_> which kind of info?
[14:56:24] <DWKnight> a lot more info than can be provided in the 90 seconds I have left at my computer
[14:56:41] <flo_> aha... i am unable to connect to port 6881 from outside...
[14:56:48] <flo_> (tried with telnet)
[14:56:52] <flo_> so i AM firewalled, right?
[14:57:04] <DWKnight> most likely
[14:57:26] <DWKnight> although most clients don't use 6881 as a default port anymore
[14:58:05] <flo_> transmission seems to do.
[14:58:23] <flo_> yay =) data rate grew...
[14:58:28] <flo_> from 20 to 60
[14:58:42] <flo_> still not very fast, though :/
[15:02:24] *** Gottaname has joined #bittorrent
[15:05:13] *** goussx_ has joined #bittorrent
[15:05:13] *** goussx_ has joined #bittorrent
[15:05:50] *** goussx has quit IRC
[15:05:50] *** goussx_ is now known as goussx
[15:06:37] *** Switeck has quit IRC
[15:12:50] <charles> transmission does not use 6881 as a default port... hasn't for years
[15:19:32] *** trelane` has joined #bittorrent
[15:20:01] *** trelane has quit IRC
[16:39:09] *** flo|linux has joined #bittorrent
[16:41:41] *** flo_ has quit IRC
[17:19:58] *** flo_ has joined #bittorrent
[17:21:01] *** flo|linux has quit IRC
[17:21:03] *** flo_ is now known as flo|linux
[17:35:21] *** flo|linux has quit IRC
[17:59:09] *** Miller` has quit IRC
[18:14:05] *** GTHK has joined #bittorrent
[18:14:41] *** goussx has quit IRC
[18:23:31] *** edigaryev has quit IRC
[18:26:22] *** neurodrone has joined #bittorrent
[18:26:25] *** neurodrone has joined #bittorrent
[18:35:21] *** edigaryev has joined #bittorrent
[18:43:35] *** mxs_ has joined #bittorrent
[18:43:35] *** mxs has quit IRC
[18:43:35] *** mxs_ has quit IRC
[18:43:35] *** mxs_ has joined #bittorrent
[18:43:53] *** mxs_ is now known as mxs
[18:44:13] <charles> WhatMan: ping
[18:44:20] <charles> WhatMan: is a PM okay?
[18:51:10] <alus> haha, "the torrent of malware"
[18:51:32] *** andar2 has joined #bittorrent
[18:51:33] <charles> ?
[18:52:21] <alus> http://www.theregister.co.uk/2010/02/17/spam_botnet_trends/
[18:54:25] *** goussx has joined #bittorrent
[18:55:42] *** JudgeSHAD0W has joined #bittorrent
[19:16:01] *** burris has quit IRC
[19:17:02] <WhatMan> Sure, charles. Can't chat long though, making dinner.
[19:24:19] *** MassaRoddel has joined #bittorrent
[19:28:08] *** Snoopotic has joined #bittorrent
[19:32:53] *** Snoopotic has quit IRC
[19:34:27] *** Snoopotic has joined #bittorrent
[19:36:26] *** _rafi_ has joined #bittorrent
[19:42:56] *** pevangelista has joined #bittorrent
[19:44:04] <pevangelista> Hi all!
[19:44:15] <pevangelista> Simple question, today =)
[19:44:18] *** neurodrone has quit IRC
[19:45:24] <pevangelista> If the client sends a 'not interested' message to a peer, does this peer need to send a choke message back to the client?
[19:49:05] <alus> yes
[19:49:53] <alus> it's perhaps not strictly required, but it is polite and clients I know of do it
[19:53:55] <pevangelista> Thanks!
[20:00:11] <pevangelista> I was reading an article about bittorrent, and I saw a sequence diagram exemplifying the exchange of messages between peers
[20:02:04] <pevangelista> In this diagram, right after the peers exchanges bitfields, the client sends requests to the connected peers, even though it is still choked
[20:02:38] <pevangelista> In my reasoning, it makes more sense to send request messages only when unchoked. So, what is the best/correct approach?
[20:06:31] *** edigaryev has quit IRC
[20:08:39] <alus> pevangelista: sounds like that diagram was wrong
[20:08:53] <pevangelista> That's what I thought
[20:09:16] <alus> pevangelista: the corrent thing is for client A to send "interested" to B, and for B to respond with "unchoke" and then A can send requests
[20:09:34] *** The_8472 has quit IRC
[20:09:44] <alus> there are quite a few round-trips before bittorrent can really do anything :/
[20:11:42] *** edigaryev has joined #bittorrent
[20:15:17] *** The_8472 has joined #bittorrent
[20:18:55] *** edigaryev has quit IRC
[20:20:07] <pevangelista> Because the specification is kind of loose, and because this article was accepted in an international conference, I was in doubt. It keeps me thinking about the quality of articles accepted..
[20:21:49] <alus> the specification is poorly documented. it's pretty clear if you look at implementations
[20:24:24] <The_8472> <pevangelista> In this diagram, right after the peers exchanges bitfields, the client sends requests to the connected peers, even though it is still choked <- that should not happen. at all.
[20:25:31] <The_8472> at the very least the peers have to exchange interested and allow-fast or unchoke messages before the first request can be done
[20:25:58] <alus> The_8472: what do you think of removing the "intersted" state, and having pending requests indicate interested vs. not interested?
[20:26:25] <pevangelista> <The_8472> Yeah, after a more careful thinking, I realized this is a great waste of resources.
[20:26:46] <The_8472> alus, i don't think it's a good idea. interested makes things clear and requires less infering
[20:26:54] <The_8472> especially in the case of selective downloads
[20:26:57] <pevangelista> <alus> I think that would be bad. Because the Client would have to keep all these requests somewhere
[20:27:30] <alus> The_8472: pending.length() > 0 is not that hard..
[20:27:54] <The_8472> why would they be pending?
[20:28:06] <The_8472> i send a request, you haven't unchoked me... you cancel it. nothing pending
[20:28:24] <The_8472> and you only know who to unchoke in the first place if you know who's interested
[20:28:25] <alus> oh. don't cancel it.
[20:28:34] <The_8472> err
[20:28:36] <The_8472> reject
[20:28:41] <pevangelista> but what if you never unchoke the peer?
[20:28:42] <alus> right, remove reject too
[20:28:47] <pevangelista> you just wasted resources
[20:28:56] <The_8472> you can't do that
[20:28:59] <alus> the resources it takes to store the request in memory?
[20:29:07] <alus> that's not very much..
[20:29:14] <The_8472> the requests might be out of date because you have that partial piece from another source
[20:29:18] <pevangelista> or what if this peer downloads these requested pieces from other peer?
[20:29:34] <The_8472> seriously, interested should stay. if there are issues with it we should clarify the spec
[20:29:39] <alus> The_8472: right. if you're so far along that you're starting to overlap requests you sent out long ago, you can cancel those
[20:29:56] <alus> and issue new requests, if you want
[20:30:08] <alus> that should only happen near the end, where you probably go in to end-game anyway
[20:30:25] <The_8472> far along? i want to finish pieces, so i have to cancel pretty fast...
[20:30:40] <The_8472> i want instant gratification on requests so to speak
[20:30:47] <The_8472> either a reject or a piece message.
[20:30:48] <alus> so what's the difference between going to in to end-game with everyone who has you unchoked, and going in to end-game with everyone, hoping that maybe one will unchoke you who hadn't
[20:31:00] <The_8472> no lingering requests that may or may not get answered anytime soon
[20:31:27] <alus> what's wrong with a lingering request?
[20:31:38] <The_8472> rate control
[20:31:55] <The_8472> request scheduling for pieces
[20:31:57] <The_8472> ... everything
[20:32:10] <The_8472> not to mention that i see no point in changing all this
[20:32:21] <alus> ah, download rate control through rate-limiting requests. only AZ does that
[20:32:51] <alus> you could still do that if you want - don't issue more pendings than you want to
[20:32:51] <The_8472> i think TheSHAD0W was experimenting with # of requests in-flight control
[20:33:37] <alus> do you avoid sending "interested" if your request limiter is maxed out?
[20:33:38] <Nolar> i'd need to think about it more, but blindly sending out requests, with no idea if or when they'd ever get responded to sounds like trouble
[20:34:02] <Nolar> at what point do i ask another peer for the same?
[20:34:17] <alus> Nolar: when you have nothing else to request. end-game.
[20:34:26] <Nolar> yuck
[20:34:47] <The_8472> alus, no. i need the additional (but unused) unchokes to pump out additional requests if necessary
[20:35:14] <alus> The_8472: that only reduces the latency of starting up a new request
[20:35:28] <alus> The_8472: with this change, all you would have to do is send a request
[20:35:28] <The_8472> latency is pretty important for the way the rate limiter works
[20:35:44] <Nolar> not all pieces are equal
[20:36:05] <alus> I agree. reducing latency is good. if you didn't have to send "interested" then wait for "unchoke" then send a reqeust, you would have the same latency
[20:36:14] <Nolar> i'd hate to have asked peers for all the important ones
[20:36:33] <alus> Nolar: you can of course send cancels if you change your mind
[20:36:49] <The_8472> it is based on the assumption that the requests won't linger, i.e. will be answered immediately. so that the request rate is approximately equal to the receive rate
[20:36:50] <Nolar> uhg
[20:37:03] <Nolar> why is this even a topic of discussion?
[20:37:20] <The_8472> alus... it somehow looks like a solution looking for a problem
[20:37:35] <Nolar> interested - unchoke - request latency doesnt matter
[20:37:38] <alus> I'm just wondering why there's all this extra state in there
[20:37:45] <Nolar> ask bram :)
[20:38:01] <The_8472> it's not an extra state
[20:38:14] <alus> I did. He just likes it better.
[20:38:40] <alus> <Nolar> interested - unchoke - request latency doesnt matter <-- tell The_8472 that
[20:38:42] <Nolar> heh
[20:38:42] <The_8472> it makes things explicit. peers have more knowledge about what's going on on each end
[20:39:14] <The_8472> request latency matters, interested-unchoke-request latency doesn't
[20:39:17] <alus> well, it's different state
[20:39:28] <alus> you know the peer is interested, but you don't know what they might request if you unchoked them
[20:39:29] <The_8472> because interested is signalled practically permanently
[20:39:55] <The_8472> the thing is piece picking is done in realtime
[20:40:13] <The_8472> so having requests possibly outstanding for minutes will make that request outdated
[20:40:45] <The_8472> not to mention that it'll make active piece management more akward since you have to randomly try peers that aren't unchoking you
[20:40:51] <The_8472> just to get a chance to get unchoked
[20:41:26] <The_8472> with a big swarm there's a high probability that sending a request won't be answered anytime soon. but you're forced to send requests anyway just to get unchokes
[20:41:35] <The_8472> despite knowing that it'll probably stall the piece for some time
[20:41:39] <Nolar> i dont get this latency thing, but it seems to me that sending requests willy nilly would cause more *bandwidth* usage, which imho is worse
[20:42:01] <alus> more bandwidth usage?
[20:42:20] <The_8472> superfluous requests and cancels to ALL peers
[20:42:29] <alus> I guess it does cause a weird situation where you have to request non-rare pieces first to avoid delaying them, and if the sender decides to choke you it could stall a rare piece
[20:42:32] <Nolar> ya, sending out requests constantly, in hopes that one will actually send me data
[20:42:38] <The_8472> since you're forced to send requests just to signal your "interested" state
[20:42:52] <alus> sending out a request isn't much worse than sending out an interested message
[20:42:57] <The_8472> no
[20:43:02] <The_8472> you send out an interested message once
[20:43:03] <Nolar> can someone clarify what problem we're trying to solve?
[20:43:08] <The_8472> and it stays interested forever
[20:43:25] <The_8472> while you have to constantly request and cancel to keep things up to date
[20:43:41] <The_8472> which is just silly
[20:43:42] *** trelane` has quit IRC
[20:43:42] *** trelane` has joined #bittorrent
[20:44:05] <The_8472> anyway. solution looking for a problem.
[20:44:16] <alus> The_8472: not if you request something very non-rare
[20:44:49] <The_8472> and why would i want to do that?
[20:44:53] <alus> Nolar: I'm just thinking out-loud about what happens if you don't have explicit interested or choke messages anymore
[20:45:06] <The_8472> oh right... to signal being interested at all, even if i don't really want THAT piece. i want rare ones
[20:45:10] <alus> The_8472: so that the outstanding request could last forever, same as the interested state
[20:45:24] <The_8472> yes, just that it's semantically incorrect
[20:45:29] <The_8472> because i don't really want that piece
[20:45:34] <alus> well you do eventually want the piece
[20:45:43] <The_8472> i don't want it now
[20:45:53] <The_8472> what i really want is to tell them i'm interested. not that i want a non-rare piece
[20:45:59] <alus> you probably want something else they have more
[20:46:07] <The_8472> exactly
[20:47:14] <alus> so you can move this request closer or farther from the top rarity.
[20:47:33] <alus> there's some distance closer than all-the-way-out, at which the probability of a collision is low
[20:47:34] <The_8472> yes, and given enough thrust pigs fly just fine
[20:47:51] <alus> yes.
[20:48:03] <alus> now we just need to figure out how to mount lasers on them
[20:48:27] <The_8472> hahaha
[20:49:00] <Nolar> there definitely is some appeal to just firing piece chunks back and forth, with less state, but i'd need to think about how it could work practically
[20:50:06] <alus> Nolar: take note of how much this looks like HTTP when you're done ;)
[20:50:18] <Nolar> what we have now?
[20:50:44] <alus> once you remove interested and choked states, yes
[20:51:10] <Nolar> in theory, the sender could know enough about the receiver to send the right chunk without having to be explicitly told
[20:51:57] <Nolar> especially when you start to break "chunks" down into nice little udp packet -sized pieces
[20:52:17] <alus> :D
[20:52:30] <Nolar> you know what http://libswift.org/ does?
[20:52:32] <alus> I haven't looked at swift, but it's possible they do that
[20:52:39] *** KyleK_ has joined #bittorrent
[20:52:41] <Nolar> what with their fancy merkle hash trees
[20:52:45] <alus> yes
[20:53:45] <alus> they don't have a piece picker yet, iirc. they just request data sequentially. so maybe they haven't made it this far
[20:54:13] <alus> it's tempting to pick it up and make it complete enough to do real swarming with.
[20:54:36] <alus> it feels like a better answer than bittorrent today
[20:55:01] <Nolar> yup
[20:55:16] <Nolar> definitely the direction i'd head in for "bittorrent 2.0"
[20:56:17] <alus> backwards compatability is the biggest pain
[20:56:28] <alus> if you wanted to try to seemlessly upgrade swarms
[21:01:48] *** KyleK_ has quit IRC
[21:05:11] <The_8472> at some point even maintaining both options within a client gets a pain
[21:05:19] <The_8472> if things are conceptually too different
[21:12:12] *** ajaya has joined #bittorrent
[21:17:38] *** KyleK_ has joined #bittorrent
[21:18:57] <JudgeSHAD0W> alus: You're wrong.
[21:19:35] <JudgeSHAD0W> The choke message is mostly independent of whether the peer is interested or not.
[21:21:13] <JudgeSHAD0W> Original BT spec left many disinterested peers unchoked when there were insufficient peers requesting to fill upload slots, so that when a peer did become interested it wouldn't take up time to unchoke him.
[21:26:20] *** KyleK_ has quit IRC
[21:27:19] <alus> JudgeSHAD0W: do clients still do that?
[21:27:27] <JudgeSHAD0W> Mine does.
[21:27:31] <alus> JudgeSHAD0W: no choker I've ever written does
[21:27:36] <JudgeSHAD0W> Hehe.
[21:27:57] <JudgeSHAD0W> Well...
[21:28:07] <JudgeSHAD0W> That'll slow things down on medium to high latency connections.
[21:28:09] <alus> I hope uT does the right thing when it becomes interested and is already unchoked...
[21:28:21] <JudgeSHAD0W> Send interested, receive unchoke, send requests...
[21:28:30] <alus> JudgeSHAD0W: but how many unchokes do you issue, and how do you know who to issue them to?
[21:28:34] <JudgeSHAD0W> Versus send interested followed immediately by requests.
[21:28:44] *** andar has quit IRC
[21:29:01] <JudgeSHAD0W> alus: If there aren't enough peers downloading, you unchoke everybody.  Otherwise you choke on schedule.
[21:29:16] <alus> ouch
[21:29:47] * alus points JudgeSHAD0W at The_8472
[21:29:53] <JudgeSHAD0W> No ouch, it makes it a little scramble when more peers send interested, but handles okay.
[21:30:37] <alus> it seems like you would have a flood of requests every time you send a HAVE
[21:30:52] <JudgeSHAD0W> No, it recalculates things when peers send interested.
[21:30:56] <alus> and you either upload to too many people, or send a lot of rejects
[21:31:22] <JudgeSHAD0W> No rejects - this is pre-fast-spec.  :-P
[21:31:37] <JudgeSHAD0W> It's no more rejects than when you normally choke someone.
[21:31:49] <JudgeSHAD0W> On rare occasions, you do send out a flurry of chokes.
[21:31:53] <alus> but you're ensuring that they send a request before you choke them
[21:32:03] <JudgeSHAD0W> Yeah, but that's no big deal.
[21:32:37] <JudgeSHAD0W> Better that IMO than the delay when peers start downloading.
[21:33:28] <alus> then you unchoke them again when the other peers you're done with finish downloading the piece
[21:33:37] <alus> possibly causing another wave of requests and chokes
[21:33:50] *** pevangelista has quit IRC
[21:33:52] <JudgeSHAD0W> I dunno, but it seems to work well.
[21:34:31] <alus> it's fine. you've just removed the "interested" state.
[21:34:57] <alus> by making everyone interested all the time, but choking them if they try to do anything and you don't actually have a slot for them
[21:35:10] <alus> The_8472: ^
[21:35:19] <JudgeSHAD0W> The other way around.
[21:35:31] <JudgeSHAD0W> It unchokes everyone who's not interested, until enough people become interested.
[21:35:49] <JudgeSHAD0W> Actually it unchokes everyone, until enough people become interested.
[21:41:21] <alus> right
[21:42:28] <alus> so essentially you don't care if they're interested or not, since interested people will send you requests if they are unchoked
[21:42:49] <alus> you pretend everyone is interested, and unchoke until you get enough peer with requests
[21:44:26] *** reseg has joined #bittorrent
[21:45:42] <reseg> hello - if I check my speed (from speedtest.net), I get a healthy 18 mega bits/sec down. If then I start my torrents, I notice a change after five minutes.... if I then pause all of my torrents and then take the test again, I get barely a 1 mega bit/sec down. What do you think could be the culprit here?
[21:46:13] <alus> reseg: which client?
[21:46:20] <reseg> Trasmission
[21:46:37] <reseg> this specific behavior only started happening two or three days ago, by the way
[21:47:17] <alus> I don't know if pausing in Transmission drops client connections or not.
[21:47:19] <alus> charles: ?
[21:47:31] <alus> but you could be experiencing ISP rate limiting.
[21:47:33] <alus> which ISP?
[21:47:40] <reseg> Time Warner Road Runner
[21:47:51] <reseg> I didn't know ISP's did that
[21:48:13] <Nolar> <JudgeSHAD0W> The choke message is mostly independent of whether the peer is interested or not. <<< wha???  if sending an unchoke doesnt depend on the peer being interested, then that's a huge bug
[21:50:15] <reseg> I'll try using a different port
[21:50:17] <Nolar> but i guess that's only a problem when you have more peers than unchoke slots
[21:59:48] *** KC9NVQ has joined #bittorrent
[22:00:50] *** trelane has joined #bittorrent
[22:01:12] *** trelane has quit IRC
[22:01:12] *** trelane has joined #bittorrent
[22:04:17] *** trelane` has quit IRC
[22:04:30] *** KC9NVQ has quit IRC
[22:45:24] *** neurodrone has joined #bittorrent
[22:53:35] <JudgeSHAD0W> http://entertainment.slashdot.org/article.pl?sid=10/02/18/0333212
[23:03:06] <alus> uh, how does changing the DNS for the tracker do anything to someone who is torrenting besides prevent it from getting a peer list?
[23:03:16] <alus> they probably never saw the rick roll...
[23:04:35] *** _rafi_ has quit IRC
[23:04:52] *** _rafi_ has joined #bittorrent
[23:05:08] <Nolar> wasnt that the point?  to reduce/remove peer traffic?
[23:05:44] <Nolar> doing more than just sending to /dev/null was a waste though
[23:19:00] *** NightOath has joined #bittorrent
[23:22:30] *** Miller` has joined #bittorrent
[23:31:42] <JudgeSHAD0W> http://www.wired.com/threatlevel/2010/02/feds-can-search-seize-p2p-files-without-warrant/
[23:32:06] <JudgeSHAD0W> Uh, yeah, if you're publishing files to the public, and anyone can download them, the Feds count as "anyone".
[23:32:34] <DeHackEd> I'm inclined to agree with that interpretation
[23:38:20] *** Snoopotic has quit IRC
[23:44:47] <alus> hahaha "verified hash marks of files"
[23:46:14] <alus> "they, uh, verificated the files using hash browns.. or pot."
[23:46:56] <DeHackEd> you'd think wired would have gotten it at least half right
[23:47:25] *** KyleK_ has joined #bittorrent
[23:48:06] *** Andrius has quit IRC
[23:56:45] <JudgeSHAD0W> OMG
[23:56:50] <JudgeSHAD0W> OT, but holy shit: http://americasright.com/?p=3159





top