[00:02:54] *** wereHamster is now known as 77CAAAP2V
[00:02:57] *** alienvenom has joined #bittorrent
[00:03:00] <burris> mpl maybe the remote peer is getting that piece from somewhere else... are you a seed?
[00:04:01] <DeHackEd> man you should see the noise in #freenode
[00:04:01] *** bittwist has quit IRC
[00:04:06] <mpl> burris: both peers are on localhost with a custom torrent for that
[00:04:12] *** ivan` is now known as Guest73475
[00:04:17] *** bittwist has joined #bittorrent
[00:04:34] <mpl> burris: one of them is mainline bt the other one is the one I'm working on.
[00:05:18] <mpl> both of them are leechers.
[00:05:34] <mpl> but they start with different pieces.
[00:06:50] <skampler> mpl: did you send a have to it?
[00:06:58] <skampler> mpl: and/or bitfield
[00:07:34] <mpl> I didn't send a have since I didn't get any request yet. yes I sent my bitfield, got an "interested" reply, then sent an "unchoke".
[00:07:38] <DeHackEd> if it's interested, then one would say yes.
[00:08:32] <mpl> so what, I need to send a "have" if I want the other peer to request that piece?
[00:08:53] <mpl> won't the other peer ask for any piece it's interested in anyway?
[00:08:55] <DeHackEd> no, the bitfield is the same a X HAVE packets
[00:09:09] *** tolkad has joined #bittorrent
[00:09:10] <mpl> right.
[00:09:22] <mpl> so I wonder why I'm not getting any request...
[00:09:23] <skampler> mpl: i know that transmission, the other client i'm testing with, sends have without getting requests
[00:09:25] *** tolkad has left #bittorrent
[00:09:26] *** 77CAAAP2V has quit IRC
[00:09:31] *** wereHamster has joined #bittorrent
[00:09:35] <skampler> mpl: it also starts with sending an incomplete bitfield
[00:09:38] *** stalled has joined #bittorrent
[00:09:52] <DeHackEd> which is to defeat some anti-seed measures by ISPs
[00:09:59] *** wereHamster has quit IRC
[00:10:01] <skampler> i see
[00:10:09] <skampler> i didn't know that :P
[00:10:28] <mpl> that's interesting, but that does not solve my problem...
[00:10:45] <skampler> mpl: send an incomplete bitfield and some haves ?
[00:11:06] <mpl> skampler: I _did_ send my bitfield.
[00:12:03] <mpl> otherwise I would not have gotten an "interested" frome the other peer.
[00:12:19] <mpl> wouldn't I?
[00:15:42] *** dlm has joined #bittorrent
[00:24:00] <burris> offtopic: anyone care to guess how fast a 266mHz pentium mmx is compared to a 1.1gHz z510 Atom?
[00:24:21] *** Joric has joined #bittorrent
[00:24:47] *** Joric has left #bittorrent
[00:25:03] <mpl> burris: I have no idea but I'm interested in the answer :)
[00:25:55] <burris> I'm not sure either but the atom isn't as substantially faster than the pentium as I had hoped...
[00:26:35] <burris> either that or linux 2.6 preempt scheduling latency sucks ass compared to 2.4-rt
[00:26:41] <DeHackEd> I compared my 1 year old Eee vs my 4.5 yearold Centrino/pentiumM.
[00:26:59] <mpl> burris: that last hypothesis is not to be dismissed so easily...
[00:28:39] <burris> mpl: I was hoping the preemptive kernel had low scheduling latency, the most recent realtime patch for 2.6 crashed (but 2.6 preempt is now crashing when recording from two cards)
[00:30:13] *** goussx has joined #bittorrent
[00:30:43] <burris> DeHackEd, surprising results?
[00:30:58] <DeHackEd> the FPU on the atom is horrible. the integer unit is merely subpar
[00:31:41] <skampler> so what's a good strategy for implementing asynchronous data handling in a client
[00:31:44] <DeHackEd> the atom at 1.6 and the pentium at 1.86 GHz I expected the atom to lose, but it's a lot worse than I expected....
[00:32:01] <skampler> a select/poll loop and keeping track of the last message for every peer?
[00:32:25] <skampler> in C
[00:32:47] <burris> you should use an async networking package like libowfat
[00:32:55] <DeHackEd> or libevent ?
[00:33:08] <burris> or libevent, couldn't remember the name of that one
[00:33:12] <DeHackEd> which will use kqueue on BSD or epoll on linux
[00:33:30] <skampler> ok
[00:34:31] <burris> yeah so bram has a new project he's been working on for a year in python, do you think he used twisted or even asyncore??
[00:35:17] <dlm> http://bramcohen.livejournal.com/72298.html
[00:35:52] <DeHackEd> we've seen it...
[00:36:01] <DeHackEd> I'd post but I don't have an lj.com account
[00:38:02] <burris> bram forgets that he no longer heads up any important opensource projects
[00:38:54] <burris> if he ever did
[00:39:06] <chelz> eh yeah i wonder how popular bittorrent got before it became utorrent
[00:39:13] <chelz> that's not very open source, for the record. heh
[00:41:33] <mpl> wow, I didn't know he was that kind of guy.
[00:42:13] <mpl> I thought only people appearing in paparazzi shots behaved like that...
[00:42:53] <burris> even if there weren't other open source implementations that have always been more popular with app writers and researchers, BitTorrent just isn't that important to the opensource ecosystem.  If BitTorrent disappeared tomorrow it wouldn't have much impact on opensource at all.  Even for distros that use it, it's a secondary method that isn't anywhere nearly as utilized as http or ftp.  No distros use it for autoupdate, afaik.  It
[00:42:53] <burris> 's not important to open source like the way linux, gnome, gcc, eclipse, firefox, etc... are
[00:43:53] <DeHackEd> well, when it was new it was revolutionary in terms of doing what it's designed to do
[00:44:05] <chelz> somewhere between 60-80% of comments i'm seeing on that story are calling him a "douche" or calling it "douche behavior"
[00:44:12] <DeHackEd> but the fanfare's sorta died down and now it's approaching everyday internet use.
[00:44:39] <mpl> well, there may be more ppl pirating stuff with bt all over the world than linux users.
[00:44:47] <burris> no, ed2k and swarmcast predated BT by quite a bit
[00:45:06] <DeHackEd> but did they facilitate big downloads quickly without queues?
[00:45:13] <DeHackEd> (that's an honest quesotin, I don't know the answer)
[00:45:57] <burris> it still doesn't make BT an important open source project...  also, the part that bram got right was not having a big global system like ed2k, which has a power law distribution of files to nodes and leads to long queues
[00:46:01] <TheSHAD0W> I remember new distro downloads used to be horribly painful.
[00:46:33] <TheSHAD0W> What was it, Debian, that had a release where you were lucky to get 2 kbps?
[00:46:52] <burris> but now everyone uses http with no problems, maybe I'm not downloading them on day 0 but using hhtp is faster than bt these days
[00:48:30] <dlm> actually, bt is still the only the max out my connection, all 24mbps of it
[00:49:51] <chelz> well say if bt moved over to using collections of per-file hashes in torrents and peer discovery was all through the DHT. what would the difference be between BT and say emule in terms of long queues and files/nodes?
[00:50:46] <TheSHAD0W> Security.
[00:50:59] <TheSHAD0W> And, if BT were run to spec with seed servers, speed.
[00:52:01] <chelz> security as in encrypted connections between peers?
[00:53:18] <chelz> i guess the speed differences are due to technical differences in queuing and the DHT protocol. but if things do move to a per-file system with the DHT, it seems like emule wasn't too far off with Kad in terms of what works
[00:58:01] *** Switeck has joined #bittorrent
[00:58:58] <The_8472> ed2k evolved a lot since it was first implemented. it got more... BT-like over time
[01:00:38] *** plus has joined #bittorrent
[01:07:25] <chelz> perhaps. sounds great if it means faster speeds. it would be great to get torrent-like speeds on ed2k. but i don't see emule index sites overtaking bt index sites.
[01:12:56] *** dlm has quit IRC
[01:20:32] <The_8472> well, i was more referring to kad and how they handle pieces - which are still larger than the largest pieces in BT
[01:24:07] <The_8472> alus, did anything interesting happen on the BT conference?
[01:36:17] *** VirtualCtor has joined #bittorrent
[01:38:13] *** VirtualCtor has left #bittorrent
[02:16:32] <DWKnight> ed2k - 9500*1024 byte pieces
[02:16:34] <DWKnight> fixed size
[02:18:00] *** chris_99 has quit IRC
[02:28:38] *** faux` has quit IRC
[03:06:36] *** stalled has quit IRC
[03:10:55] *** stalled has joined #bittorrent
[03:35:27] *** maJiC has quit IRC
[03:42:08] *** laars has joined #bittorrent
[03:43:31] <laars> hi. after having started the download of a very large torrent, that probably connects to very many peers, does the router sort of slow up?
[03:44:09] <laars> I'm not technically savvy enough to say it properly, but I've a hunch that that's why my internet is a bit slow. When this happens, should I just keep periodically restart my router?
[03:44:43] <The_8472> you are probably connecting to too many peers. neither the size of the torrent nor the size of the swarm should have any impact
[03:45:03] <The_8472> the number of connections used by a bittorrent client usually is around 60-100, more isn't needed
[03:45:20] <The_8472> but yes, routers can behave badly if there are too many connections
[03:45:33] <skampler> The_8472: 60-100 per torrent?
[03:45:35] <laars> well, even after I've paused the download, for example. Isn't the IPs (for whatever purpose) kept in the router? does that slow it up?
[03:46:42] <The_8472> skampler, well... less would do too in most cases. but you need some pool to unchoke
[03:47:24] <laars> I started a 150 GB torrent yesterday. I was getting easily 800 KB/sec stable for the first 8 hours.. and it gradually began to slow down. (and not just the torrent - e.g., I felt youtube videos and everything else to be slower)
[03:47:25] <The_8472> laars, i think you mean "slow it down". but yes, the router keeps track of all connections that are currently open
[03:48:08] <The_8472> unless you have a reeeaaaally bad router... some have asinine timeouts, like 5 days
[03:48:08] *** XX01XX has joined #bittorrent
[03:48:23] <chelz> laris your upload capped?
[03:48:37] <chelz> always cap at 80% of your maximum upload
[03:48:43] <skampler> The_8472: sure but did you mean per torrent or globally?
[03:48:59] <laars> the upload didn't cap, no
[03:49:04] <The_8472> skampler, per torrent. and of course the number of concurrently active torrents should be limited
[03:49:30] <skampler> limited in what sense?
[03:49:36] <skampler> er
[03:49:42] <The_8472> as in 1. or 2.
[03:50:46] *** XX01XX has left #bittorrent
[03:50:49] <Switeck> At the absolute WORST, each torrent's upload slots should get 2 KB/sec
[03:51:00] <The_8472> uhm
[03:51:12] <The_8472> that's too low
[03:51:38] <Switeck> too low compared to real-world results? XD
[03:51:56] <The_8472> too low compared to efficient usage
[03:52:14] <Switeck> well, "WORST" automatically implies it's already inefficient usage
[03:52:18] <The_8472> under congestion you have to consider significant round trip times. i've seen RTTs of ~3 seconds
[03:52:51] <Switeck> and satellite connections might fight with that kinda RTT all the time.
[03:53:09] <The_8472> yeah. so it takes a while after an unchoke to ramp things up
[03:53:20] <Switeck> I prefer more like 5-10 KB/sec per upload slot
[03:53:25] <The_8472> and you want to transfer at least 1 chunk (16KiB) within one unchoke
[03:53:53] <Switeck> if unchokes are lasting less than 10 seconds, your code's busted XD
[03:53:57] <The_8472> unchoke lasts 10 seconds (30 for optimistics), if you take away 1-2 RTTs ....
[03:54:14] <The_8472> so 2 is too low
[03:54:28] <Switeck> why 10 seconds?
[03:54:38] <Switeck> that's not effecient
[03:54:46] <laars> isn't there some client out there that dynamically deals with these types of situations? resets upload rates to prevent chokes and so on?
[03:54:52] <The_8472> 10s unchoke interval is what's specified
[03:54:57] <Switeck> And optimistic unchokes at 30 seconds aren't really either.
[03:55:09] <The_8472> huh?
[03:55:15] *** wnoise has joined #bittorrent
[03:55:17] <Switeck> 30 seconds even at 10 KB/sec won't net a whole 512 KB piece
[03:55:22] <The_8472> so?
[03:55:25] <Switeck> so?
[03:55:38] <The_8472> choking is not about transfering whole pieces.
[03:55:45] <Switeck> it is implied
[03:55:48] <The_8472> not really
[03:55:55] <Switeck> that there must be a decent chance for new peers to get a complete piece
[03:56:07] <The_8472> they can just resume from a different pere
[03:56:14] <The_8472> not to mention that there's the fast extension
[03:56:59] <The_8472> (un)choke timescales should NOT be based on piece sizes. otherwise leeching would be trivial on torrents with 4MB pieces
[03:57:00] <Switeck> Anyway...the average upload speed for upload slots factored across many ADSL and Cable lines is indeed 2 KB/sec OR LESS.
[03:57:32] <The_8472> yeeah, some people need to be shot. repeatedly
[03:57:40] <Switeck> you'd be shooting a *LOT* of people
[03:57:52] <The_8472> then i have to recycle ammunition
[03:58:02] <The_8472> or maybe use a crossbow
[03:58:04] <Switeck> Does Vuze prevent ridiculous settings?
[03:58:43] <Switeck> Example: 1 KB/sec upload speed max, 10 torrents, 10 upload slots each...
[03:59:12] <laars> what are your thoughts on Transmission? (I'm using it, hence my asking, especially with respect to the problem I was having)
[03:59:15] <Switeck> Even if you respect the 1 KB/sec upload limit, 10 upload slots per torrent is pointless.
[03:59:29] *** The_8472 has quit IRC
[03:59:33] *** The_8473 has joined #bittorrent
[03:59:33] *** The_8473 is now known as The_8472
[03:59:51] <The_8472> only for some cases, like minimal upload speed
[04:00:01] <The_8472> or number of downloading vs. active torrents overall
[04:00:09] <The_8472> but yeah, there's still a low you can screw up
[04:00:18] <Switeck> 10 downloading torrents max, with 5 global max active torrents XD
[04:00:39] <The_8472> that won't work
[04:00:50] <The_8472> downloading < 0.5 * max active
[04:00:56] <The_8472> <= i think
[04:01:48] <Switeck> I'm asking if Vuze prevents that...which is technically "impossible" settings
[04:02:23] <The_8472> oh, impossible things are not possible, yeah ^^
[04:02:37] <trelane> The_8472, you can't reuse ammunition
[04:02:47] <trelane> you can reload cheaply with the case and a new bulelt and some powder
[04:02:55] * trelane molests his 45ACP reloading kit
[04:03:17] <The_8472> of course you can. all you have to do is reassmbling the atoms into their previous state
[04:03:39] <The_8472> and maybe scrape a bit of carbon and hydrogen from the atmosphere
[04:04:24] <Switeck> tungsten carbide bullets...minimal deformation
[04:04:37] <The_8472> you still need the explosives
[04:05:21] <The_8472> and tungsten carbide is a ceramic, it might not deform, but it can fracture on impact.
[04:05:43] <Switeck> yeah, if it hits something REALLY hard at high velocity
[04:05:43] <The_8472> well, i guess not when impacting human flesh. but the wall behind it
[04:07:23] <Switeck> 1 way to reduce bad BitTorrent settings ...might be YouTube banning "speedup" videos.
[04:07:54] <The_8472> though i guess reusing crossbow bolts would be somewhat more feasible than nanoscale reassembly of ammunition ^^
[04:08:09] <The_8472> or banning stupid people from using it
[04:11:23] *** deltab has joined #bittorrent
[04:11:59] <Switeck> If someone's connecting TO you from their port 50, there's a high probability they're using one...
[04:12:00] <DeHackEd> The_8472: on the topic of freenode spam, should I go back onto high alert?
[04:13:10] <The_8472> hrrm...
[04:13:36] <The_8472> they need to use real IRC clients now
[04:13:46] <The_8472> i think if they're trolling now it won't be as massive as before
[04:15:04] <DeHackEd> it'll be harder to recruit victims. but it will still happen. between open proxies and maybe a few throwaway servers you could do some damage...
[04:17:43] <The_8472> sure, but once they get a k-line they have to go through more effort for the next attack
[04:17:52] <The_8472> so they can't hit many channels at once
[04:20:29] *** Mediaprodigy has joined #bittorrent
[04:24:38] *** Mediaprodigy has quit IRC
[04:47:42] *** C0ffeeMan has joined #bittorrent
[04:47:42] *** C0ffeeMan has joined #bittorrent
[05:10:06] *** The_8472 has quit IRC
[05:15:18] *** chelz has quit IRC
[05:21:48] *** chelz has joined #bittorrent
[05:22:28] *** chelz has joined #bittorrent
[05:22:28] *** Nolar has quit IRC
[05:25:18] *** M3 has joined #bittorrent
[05:25:25] <M3> hi
[05:26:11] <M3> anyone here? having trouble downloading a torrent
[05:26:28] *** Nolar has joined #bittorrent
[05:26:29] *** Nolar has joined #bittorrent
[05:27:52] *** M3 has left #bittorrent
[05:38:58] *** bramm has joined #bittorrent
[05:39:18] *** init0 has quit IRC
[05:39:34] <bramm> unfortunately it's now been well established that freenode is less than helpful at fixing channel admin problems
[05:40:30] *** Nolar has quit IRC
[05:40:39] <bramm> although it sure seems quiet in here
[05:40:55] <laars> :( you don't have access still, huh
[05:41:31] *** init0 has joined #bittorrent
[05:41:45] <bramm> nopers, and apparently it takes over a year to get through the queue
[05:42:35] <bramm> http://bramcohen.livejournal.com/72298.html
[05:44:06] <laars> that does seem strange -- I'd have thought that if you e-mail them from an e-mail that's verifiably yours, they'd hand over ownership access to you to your new nick in no time
[05:44:53] <bramm> it would take them like five minutes to do enough web research to verify that bram at bittorrent dot com is my email address, and that's apparently too much
[05:44:58] *** Nolar has joined #bittorrent
[05:44:59] *** Nolar has joined #bittorrent
[05:47:00] <laars> the nick you were trying to get back (bram, was it?) is now registered?
[05:47:27] *** C0ffeeMan has quit IRC
[05:47:37] <Switeck> Or does freenode have a policy of "expired" nicks being unusable?
[05:47:43] <laars> I can understand freenode's reluctance to hand THAT over, but giving you access on a newly-chosen nick should have been a non-issue
[05:48:22] <bramm> you would think
[05:49:00] <bramm> expired nicks are usable, and my old one has been taken over
[05:54:06] *** Nolar has quit IRC
[05:54:58] *** laars has quit IRC
[05:58:49] *** Nolar has joined #bittorrent
[05:58:49] *** Nolar has joined #bittorrent
[06:05:38] *** Nolar has quit IRC
[06:06:19] *** semaphore has joined #bittorrent
[06:10:09] *** Nolar has joined #bittorrent
[06:10:10] *** Nolar has joined #bittorrent
[06:16:38] *** Nolar has quit IRC
[06:21:21] *** Nolar has joined #bittorrent
[06:21:22] *** Nolar has joined #bittorrent
[06:24:45] *** edigaryev has joined #bittorrent
[06:26:30] *** Nolar has quit IRC
[06:29:11] *** Nolar has joined #bittorrent
[06:29:12] *** Nolar has joined #bittorrent
[06:29:53] *** ozus has joined #bittorrent
[06:31:53] *** edigaryev has quit IRC
[06:50:45] <chelz> bramm: are you close to anything on that p2p streaming project worth making an lj post about?
[06:52:25] <bramm> chelz, not really, I'm in the middle of a bunch of stuff with it right now
[06:53:24] <bramm> there's been lots of progress, but the details are all very technical and not stuff I wish to discuss yet
[06:55:31] <chelz> bramm: speaking for myself, any sort of update sure would be fun to read. i'm sure as long as the post is prefaced with a disclaimer that it's still a work in progress it would be ok, but i understand you wanting to wait.
[06:55:37] <chelz> looking forward to the next post on it
[06:56:05] <bramm> we'll probably come out with stuff about uhttp sooner
[06:56:12] <bramm> I was working on that today
[06:56:46] <chelz> that sounds interesting
[06:57:54] <bramm> it's small but useful, but I have too much of a headache right now to explain it
[06:57:55] <bramm> good night
[06:57:59] *** bramm has quit IRC
[06:59:57] *** ozus has left #bittorrent
[07:09:59] *** _rafi_ has joined #bittorrent
[07:31:50] *** alus has quit IRC
[07:40:18] *** wnoise has left #bittorrent
[07:51:01] *** alus has joined #bittorrent
[08:04:36] *** alus has quit IRC
[08:12:34] *** alus has joined #bittorrent
[08:39:58] *** ciesto has joined #bittorrent
[08:42:13] *** takeda has joined #bittorrent
[08:48:24] *** Switeck has quit IRC
[09:01:31] *** GTHK has quit IRC
[09:08:54] *** edigaryev has joined #bittorrent
[09:35:34] *** w0uq has joined #bittorrent
[10:52:03] *** ciesto has left #bittorrent
[11:21:43] *** allan has joined #bittorrent
[11:49:56] *** MassaRoddel has joined #bittorrent
[12:20:55] *** allan has left #bittorrent
[12:43:43] *** Andrius has joined #bittorrent
[12:58:01] *** ciesto has joined #bittorrent
[13:39:34] *** kwinz2 has joined #bittorrent
[13:52:55] *** edigaryev has quit IRC
[15:14:05] *** The_8472 has joined #bittorrent
[15:56:31] *** Mazon has joined #bittorrent
[15:58:04] *** Mazon has quit IRC
[15:58:58] *** Mazon has joined #bittorrent
[15:59:02] *** Mazon has quit IRC
[16:14:34] *** ciesto has left #bittorrent
[16:17:54] *** echelog has joined #bittorrent
[16:22:06] *** Guest73475 has quit IRC
[16:22:26] *** ivan` has joined #bittorrent
[16:58:09] *** GTHK has joined #bittorrent
[17:08:22] *** hlindhe has quit IRC
[17:08:23] *** 13WAAAOG3 is now known as hlindhe
[17:24:37] *** bramm has joined #bittorrent
[17:27:37] *** stalled has quit IRC
[17:29:20] *** stalled has joined #bittorrent
[18:08:40] *** goussx has quit IRC
[18:18:34] *** TheSHAD0W has quit IRC
[18:27:51] *** kwinz2 has quit IRC
[18:35:59] *** neurodrone has joined #bittorrent
[18:40:09] *** Miller` has quit IRC
[18:40:43] *** Miller` has joined #bittorrent
[18:41:35] *** kwinz2 has joined #bittorrent
[19:04:05] *** kwinz2 has quit IRC
[19:14:29] *** mpl has quit IRC
[19:17:49] *** kwinz2 has joined #bittorrent
[19:27:36] <charles> alus: wrt our conversation yesterday about something that sucks less than irc or freenode... it's still irc, but oftc looks like a viable alternative to freenet
[19:27:55] <charles> s/freenet/freenode/
[19:32:08] <The_8472> sucks less than IRC? irc has many advantages of spoken conversation imo.
[19:32:33] <The_8472> you seem to be mixing up server policy/spam issues with the system itself.
[19:32:47] <charles> The_8472: it's a similar IRC service whose administration may suck less than freenode's
[19:32:51] <The_8472> *many advantages over spoken conversation
[19:32:59] <charles> The_8472: hence my saying "it's still irc"
[19:33:17] <The_8472> you're saying as if that were a bad thing.
[19:33:22] * The_8472 <3 irc
[19:33:46] <charles> The_8472: I was referring to alus' assertion yesterday that irc sucks; not adding my own interpretation
[19:34:22] <The_8472> i see
[19:34:52] <charles> apparently OFTC forked from freenode in 2001 due to differences in opinion on management and fundraising.  long-timers probably know more about this than I do
[19:36:23] *** Mazon has joined #bittorrent
[19:37:03] <bramm> I was around then, but wasn't cognizant of the formation of oftc, I mostly stick to my own business
[19:37:58] *** Mazon has quit IRC
[19:38:22] <charles> today was the first I'd heard of it as well
[19:38:38] <charles> from a comment left in your LJ entry
[19:40:00] *** Mazon has joined #bittorrent
[19:40:27] <bramm> I'd heard of it, but wasn't aware of the reason for its existence - actually even used it, #dnalounge was, (and probably is) over there
[19:40:56] *** mpl has joined #bittorrent
[19:41:11] <kjetilho> #debian moved over there, too
[19:42:44] *** neurodrone has quit IRC
[19:43:39] <bramm> I'm working on uhttp now
[19:44:25] <bramm> got my head wrapped around encoding for RSA now - it's a lot less problematic than I feared, since you can just use an all or nothing transform
[19:45:10] *** l0de has joined #bittorrent
[19:45:14] <l0de> I hope you realize that you just completely pissed off one of the most well known and respected people in the whole open source community
[19:45:16] <l0de> I hope you realize that you just completely pissed off one of the most well known and respected people in the whole open source community
[19:45:17] <l0de> I hope you realize that you just completely pissed off one of the most well known and respected people in the whole open source community
[19:46:28] <DWKnight> obvious troll is obvious
[19:46:52] <Mazon> spamming in #freenode too
[19:47:00] <Mazon> note sure whats up
[19:47:12] <l0de> I am furious
[19:47:26] <kjetilho> so you don't know what's he's refering to?
[19:47:37] *** l0de has quit IRC
[19:47:53] <bramm> we're making uhttp due to, ahem, deficiencies in the utp tracker protocol
[19:48:26] <charles> what deficiencies?
[19:48:56] <bramm> it doesn't extend, and it's generally a pain in the ass
[19:50:28] * kjetilho . o O ( IPv6? )
[19:52:15] <DWKnight> among other things
[20:00:11] <bramm> does anybody know how to represent ipv4 addresses in ipv6?
[20:04:32] <DWKnight> not right off
[20:05:58] <kjetilho> bramm: use ::/96
[20:06:35] <kjetilho> often written simply ::192.168.0.1/128 rather than using hex nybbles
[20:06:56] <bramm> uh, not sure what that means
[20:07:12] <kjetilho> it's not supposed to be *usable* as an IPv6 address, though.  just a representation.
[20:07:30] <kjetilho> it just means set the first 96 bits to zero
[20:13:36] *** Miller` has quit IRC
[20:17:00] <bramm> but I assume that setting the first 96 bits to zero is actually an invalid IPv6 address, so client software can take such a thing to mean revert to IPv4?
[20:17:53] <kjetilho> yes
[20:18:03] <bramm> by the way, does *anything* use non-compact these days? would it be bad to simply drop it as a key and always go with compact?
[20:19:08] <kjetilho> there's a tiny exception for 0.0.0.0, it will overlap with the valid IPv6 address 0::0 which means *any* address.  but 0.0.0.0 is not used anyways (it's an alias for 127.0.0.1)
[20:20:17] <bramm> yeah, that's not a concern for what I'm doing right now
[20:21:39] <kjetilho> hmm.  perhaps it is better to use ::ffff:0:0/96, the OS will actually do something about such addresses.
[20:22:34] <bramm> what will it do with them?
[20:22:58] <kjetilho> the Right Thing :-p
[20:23:09] <bramm> ah
[20:23:14] *** neurodrone has joined #bittorrent
[20:23:33] <DWKnight> a few trackers used in the wild will still assume that no compact key in the request means compact isn't supported and will send a non-compact reply
[20:24:48] <bramm> hmm, how annoying
[20:25:06] <bramm> well, since it isn't realyl a problem probably best not to touch it
[20:27:41] <charles> bramm: according to a person who had the same nick problem last year @ <http://changelog.complete.org/archives/1102-another-freenode-annoyance/comment-page-1>, "OFTC doesn?t ever delete nickserv registrations."
[20:28:32] <bramm> good to hear
[20:28:48] <K`Tetch> could just get a unique nick
[20:29:23] <K`Tetch> 'bram' is kinda common
[20:29:49] <DeHackEd> I still think freenode policy is stupid.
[20:30:10] <K`Tetch> me to, s'why we removed the official US pirate party channel from here last week
[20:30:27] <DeHackEd> to where?
[20:30:35] <DeHackEd> not going to join, just curious
[20:30:35] <K`Tetch> went to a small private server
[20:30:39] <DeHackEd> ah
[20:30:41] <K`Tetch> run by one of our members
[20:31:10] <K`Tetch> 3 servers, 46 clients right now
[20:32:11] <K`Tetch> (irc.name141.com for anyone who is interested)
[20:32:19] <The_8472> <DeHackEd> I still think freenode policy is stupid. <- well, most networks with nickserv or something similar have expiration policies for nicks.
[20:32:42] <DeHackEd> not that policy. expiring makes a degree of sense. I'm still on about # vs ## vs getting something regsitered and supported
[20:32:53] <bramm> at the time I registered 'bram', hardly anyone was on freenode, then openprojects, and there was no nick expiration
[20:32:58] <DeHackEd> I like the bit where when staff came in they would remind us to add them to the chanserv access list when, you know, WE CANT.
[20:33:28] <bramm> what's the chanserv access list?
[20:34:04] <DeHackEd> me with basic ops, and the freenode-staff metaaccount with full ownership
[20:34:07] <DeHackEd> that's it
[20:34:39] <bramm> the staff was asking for ops?
[20:34:44] <bramm> I'm not sure what they were requesting
[20:35:24] <DeHackEd> it's happened once or twice that we (as a channel) get a troll and I'm not here so someone asks a freenode staff member to give `em the boot.
[20:37:22] *** chelz has quit IRC
[20:37:24] <bramm> so the freenode staff member comes in and does it? or they come in here asking to be opped themselves?
[20:38:04] <DeHackEd> i'd have to check my logs. I think it's more of a hassle for them to op themselves if they're not on the access list. so for speedier response they ask you add this entry to your access list which has wildcards covering all freenode staff
[20:38:20] <DeHackEd> or something to that general effect
[20:40:02] <bramm> charles: yeeesh, the bit about requiring you actually register with the nickserv instead of just log in is really nuts
[20:40:09] <The_8472> <bramm> by the way, does *anything* use non-compact these days? would it be bad to simply drop it as a key and always go with compact? <- i think some ipv6 trackers did/do that for example when peers6 wasn't standardized. and if you'd run bittorrent over i2p you need non-compact announces too
[20:40:28] <The_8472> so at least technically non-compact should remain part of the standard, even if it's rarely used
[20:42:16] <bramm> *sigh* legacy protocol negotiation stuff never goes away
[20:42:45] <The_8472> who cares. it's pretty flexible anyway. what bugs me more is the wire protocol
[20:42:54] <The_8472> like the reserved bitfield and message IDs
[20:42:58] <bramm> what is your problem with the wire protocol?
[20:43:23] <bramm> the reserved bitfield mostly isn't used in favor of the extended extension mechanism which trades bencoded messages
[20:43:33] <The_8472> flexible protocols like LTEP/AZMP are better. the problem with LTEP is that legacy messages are not first class citizens
[20:43:42] <The_8472> yes, my point
[20:43:45] <bramm> and there have never been any problems with running out of message IDs
[20:44:13] <bramm> well yes, everything uses LTEP now, but I'm not sure what you mean about messages not being first class citizens
[20:44:19] <The_8472> no, it's just crap from a design POV. the extended handshake does all we need. no point in the old wire protocol beneath it
[20:44:41] <The_8472> CHOKE uses BT message ids. ut_pex uses LTEP message IDs
[20:45:04] <The_8472> redundant redundancy is redundantly redundant.
[20:45:21] <bramm> yeah, I've come to the conclusion that dictionaries are the way to go rather than a bitfield, but it's only a few bytes per handshake and doesn't cause any problems other than the documentation being annoying to figure out if you're writing a new one from scratch
[20:46:08] <bramm> oh, umm, are ltep message ids two bytes instead of one or something? I forget
[20:46:26] <The_8472> one byte iirc
[20:46:32] <bramm> its not like the namespace is anywhere near filling up, or even starting to fill up
[20:47:11] <bramm> I looked into AZMP and came to the conclusion that it was just porting of features of ltep in a bloated encoding
[20:47:18] <The_8472> no, it's just that i would do away with it given the opportunity
[20:47:23] <The_8472> err
[20:47:30] <The_8472> AZMP is older than LTEP ^^
[20:47:46] <The_8472> and all messages are first class citizens there
[20:48:49] <bramm> regardless of which one came first, it's the exact same functionality
[20:49:04] <bramm> and azmp has a whole bunch of crud in it
[20:49:35] <The_8472> well, so does ltep imo, all the legacy junk
[20:49:44] <The_8472> but yeah, they're mostly the same
[20:50:27] <bramm> ltep doesn't bloat up the entire connection after the handshake
[20:50:37] <The_8472> huh?
[20:50:59] <The_8472> as for uhttp... this sounds a lot like overkill. something more like the DHT protocol would be better for tracker announces.
[20:51:18] <The_8472> btw, there already are standards for HTTP-over-UDP and HTTP-over-Multicast ^^
[20:51:28] <bramm> got a link for http over udp?
[20:52:31] <The_8472> it's part of the UPnP standard i think
[20:52:48] <The_8472> http://tools.ietf.org/html/draft-goland-http-udp-00
[20:54:50] <The_8472> anyway... HTTP only makes sense for compatibility purposes with webservers and what not. if you do UDP then there's no point in doing anything even close to HTTP
[20:54:56] <The_8472> it's an ugly ugly protocol ^^
[20:56:57] <bramm> there is, ahem, actively expressed interest in improvement to the UDP tracker protocol
[20:57:19] <The_8472> yes, that's ok. but it shouldn't be something HTTPish
[20:57:37] <The_8472> the DHT protocol (using bencoding) is better for that purpose
[20:57:41] <bramm> ugly it may be, but it doesn't add many bytes for tracker protocol and it avoids having to maintain extensions in parallel
[20:58:39] <The_8472> everyone doing bittorrent has to support bencoding too. so it doesn't really make sense to introduce yet-another-packet-format
[21:00:18] <bramm> weird, httpu has no anti-smurfing
[21:00:27] <bramm> and definitely no crypto
[21:01:15] <The_8472> if you do crypto... no RSA. it's too big for UDP
[21:01:33] <The_8472> use curve25519 instead
[21:02:04] <DeHackEd> rsa? that's harsh on the CPU though. is curve* public/private ?
[21:02:25] <The_8472> yes
[21:02:55] <bramm> the advantage of an http alternative is that someone can upgrade their php-based tracker to using it just by upgrading their webserver, without modifying their php at all
[21:03:21] <DeHackEd> php's popularity has dropped dramatically even without DHT helping. I wouldn't worry that much.
[21:03:24] <The_8472> except that no webserver is going to support http-over-udp.
[21:03:30] <bramm> rsa is extremely light on the cpu of the encrypting side
[21:03:32] <The_8472> that too
[21:04:43] <The_8472> rsa is clunky, it eats 256 bytes of your MTU
[21:06:31] <The_8472> ECIES with curve25519 takes 64 bytes. that's encrypting and signing.
[21:07:31] <The_8472> or if you use some unsigned handshake then it's 32 bytes
[21:08:34] <bramm> 256 bytes is only if you're being a wanker and using a 2048 bit key
[21:09:04] <The_8472> 1024bits is considered insecure now.
[21:09:33] <bramm> an altogether more reasonable 1024 bit key is 128 bytes, and for what I'm designing the entire payload of the response can be encrypted directly
[21:09:35] *** Miller` has joined #bittorrent
[21:10:31] <bramm> 'insecure' for wanker threat models, which a tracker request doesn't have, and besides, the thing I'm working on supports variable key sizes
[21:11:51] <The_8472> doesn't matter
[21:11:57] <bramm> and the crypto only has to be done on a first handshake, so even the small amount of bytes of transport it takes only get repeated once
[21:12:01] <bramm> doesn't matter for what?
[21:12:09] <The_8472> ecc is still shorter and more secure, no reason to use RSA
[21:14:33] <bramm> ecc is way more cpu on the server - http://www.cryptopp.com/benchmarks.html
[21:14:52] <The_8472> generic ECC implementations, yes
[21:15:08] <The_8472> curve25519 is optimized to perform much faster than generic ECC implementations
[21:15:21] <bramm> it's still nowhere near as fast as encrypting to rsa
[21:15:25] *** BentMyWookie has joined #bittorrent
[21:15:36] <The_8472> http://cr.yp.to/ecdh.html
[21:16:18] <bramm> yes, that's an implementation, but it's still slower than rsa
[21:16:23] <bramm> because of, you know, math
[21:16:27] <The_8472> iirc the userspace load on trackers is like 1% CPU time anyway. most of the load comes from the network stack thrashing with the high packet rate.
[21:16:51] <bramm> that ceases to be the case when you try to make them to public key crypto
[21:17:07] <bramm> and to the extent that they do public key crypto, it's almost always rsa-based for exactly this reason
[21:17:08] <The_8472> what i'm saying there's lots of room
[21:17:46] <bramm> lots of room where?
[21:17:50] <The_8472> Operation	Megacycles/Operation
[21:17:50] <The_8472> RSA 1024 Encryption	0.14
[21:18:26] <The_8472> 140k instructions. the curve needs 800k
[21:19:13] <The_8472> and offers more benefits
[21:19:31] <The_8472> like included signing, smaller packets, more security
[21:20:20] <The_8472> 600k cycles on a modern processor even
[21:21:03] <bramm> where are you getting these numbers from?
[21:21:37] <The_8472> http://cr.yp.to/ecdh/curve25519-20060209.pdf
[21:22:48] <bramm> that might be worth considering
[21:24:06] <bramm> we had discussed EC, but figured rsa is less CPU, and the extra bytes are small compared to the size of the protocol anyway
[21:25:32] <The_8472> generic ECC, yes.
[21:26:25] *** alus has quit IRC
[22:04:26] *** Miller` has quit IRC
[22:06:46] *** Miller` has joined #bittorrent
[22:12:02] <charles> I wonder if erdgeist would have any insights on server load there...
[22:14:12] <The_8472> <The_8472> iirc the userspace load on trackers is like 1% CPU time anyway. most of the load comes from the network stack thrashing with the high packet rate. <- i was paraphrasing erdgeist here
[22:17:52] <DWKnight> I can pretty much confirm that the worst bottleneck for trackers is the network stack on the OS
[22:24:40] *** r2wj has quit IRC
[22:26:30] *** r2wj has joined #bittorrent
[22:32:46] <The_8472> bramm, so... anything else resulting from the bt conference? i haven't seen any summary or so anywhere
[22:34:05] * charles is looking forward to the video
[22:34:37] * charles is still disappointed at missing about half of those sessions
[22:34:50] <The_8472> i wish i could've been there at all
[22:42:54] *** goussx has joined #bittorrent
[22:44:20] <K`Tetch> I didn't even know ther was a conference
[22:44:34] <K`Tetch> I wish I could ahve been there too
[22:49:48] *** Waldorf has joined #bittorrent
[23:12:09] <charles> K`Tetch: hydri says it was all taped, so we should be able to watch it sooner or later
[23:12:17] <K`Tetch> good good
[23:23:57] *** cgreco has quit IRC
[23:37:37] *** cgreco has joined #bittorrent
[23:37:37] *** cgreco has joined #bittorrent





top