[00:00:01] <DeHackEd> even has gzipinputstream to do compression handling
[00:00:03] <alus> can you call the functions to format/parse http from just some buffers you pass it?
[00:00:18] *** Andrius has quit IRC
[00:00:23] <alus> gzipping is not very handy for trackers
[00:00:29] <DeHackEd> not anymore
[00:01:34] <DeHackEd> actually could be good for large scrapes... I figure vuze doesn't do that anymore, but... point is, java has a good library
[00:02:15] <The_8472> <alus> can you call the functions to format/parse http from just some buffers you pass it? <- nay, we would have to use apache's libs
[00:02:28] <The_8472> which isn't all that bad
[00:02:38] <alus> The_8472: if you make your own format and say you don't fuck up and make it impossible to add new variables, you still face issues like vhosting and redirecting and such that trackers might want to do
[00:02:49] <The_8472> and php trackers use their http libs too
[00:03:09] <alus> since the whole tracker world thinks in http, supporting all the http features with a new format seemed like a pita
[00:03:34] <alus> yeah, I think with some front-end plugins for webservers to accept and send UDP packets, the PHP people can keep on as they are
[00:03:47] <The_8472> the thing is nobody really uses the HTTP features
[00:03:52] <The_8472> i mean even redirects fail with most clients
[00:04:10] <alus> that seems way easier/more useful than rewriting the trackers in some other language
[00:04:21] <alus> no one is going to do UDP in PHP
[00:05:31] <The_8472> <DeHackEd> actually could be good for large scrapes... I figure vuze doesn't do that anymore, but... point is, java has a good library <- we use multiscrapes, not full scrapes
[00:09:05] <The_8472> anyway. imo the only advantage of HTTP is library support
[00:09:14] <The_8472> otherwise is an ugly ugly protocol that should die
[00:09:23] <Nolar> support and flexibility
[00:09:37] <Switeck> That's like saying it's a bad idea that everyone uses. :P
[00:11:13] <The_8472> it is
[00:11:47] <The_8472> there is 0 support for http over udp. and we're not even really using most http features.
[00:12:16] <The_8472> because some people aren't using libraries and doing homebrewed http parsers instead which don't support most of the features
[00:12:20] <Nolar> does anything today do http via udp?
[00:12:33] <The_8472> upnp does i think
[00:12:57] <The_8472> though over a different protocol than alus is cooking up of course
[00:13:44] <The_8472> <The_8472> all the disadvantages of http and none of the advantages
[00:14:37] <The_8472> if we have to do custom http over udp parsers then nobody will support the useful http features. which makes it even more pointless
[00:15:38] <The_8472> we'll just drag around the clunky http headers in a udp world where small packet sizes count
[00:20:31] *** ivan``` has quit IRC
[00:20:31] *** wojci has quit IRC
[00:23:41] *** wojci has joined #bittorrent
[00:24:25] *** stalled has quit IRC
[00:24:29] <Nolar> best bet imho is to have http tracking like today & udp+bencoded dicts for scaling
[00:25:02] <TheSHAD0W> http://www.tuaw.com/2010/02/11/macworld-2010-adam-savage-re-enacts-the-effs-history/
[00:25:22] *** stalled has joined #bittorrent
[00:26:34] <The_8472> udp+bencoded dicts for scaling <- +1
[00:27:38] <alus> of course that was the first proposale
[00:28:26] <alus> but then think about: error responses and definitions, request/response layout with existing options
[00:28:51] <The_8472> use mainline dht stuff
[00:28:54] <Nolar> steal the http response codes :)
[00:29:06] <alus> Nolar: exactly.
[00:29:15] <alus> Nolar: now keep going...
[00:29:20] <Nolar> but i'd much rather parse bencode, than http
[00:29:36] <Nolar> if i have to write it myself
[00:30:12] *** ivan``` has joined #bittorrent
[00:30:29] <alus> Nolar: lllllllllllll
[00:30:34] <alus> etc
[00:31:22] <The_8472> 1 counter for depth of recursion...
[00:31:36] <The_8472> and all clients already have a bdecoder i assume
[00:31:54] <alus> but all trackers do not
[00:32:13] <Nolar> if i were writing a java tracker, i know how to funnel udp bytes into a http decoder, but dont know if that's true for other languages
[00:32:25] <The_8472> <alus> but all trackers do not <- how so?
[00:32:49] <alus> The_8472: why would a php tracker have a bdecoder?
[00:33:05] <The_8472> because they speak bencode-over-http
[00:33:14] <alus> Nolar: I'm assuming someone is going to have to write a piece for webservers. this could be a plugin for the webserver or simply a proxy
[00:33:27] <alus> The_8472: they -encode- bencode over http. they do not parse it
[00:33:44] <alus> The_8472: and probably the encoding is 'd' + blah + 'e' etc
[00:33:46] <The_8472> fine, for decoding .torrents then
[00:34:04] <The_8472> anyway, there are bencode/decode php classes
[00:34:18] <alus> sure, there are. how are you going to get a UDP packet in to PHP?
[00:34:54] <The_8472> i woudl say that's unrelated to using http or not
[00:34:55] <Nolar> need some sort of udp fastcgi
[00:35:40] <Nolar> but i would just say, if you're using php, stick with standard tcp+http
[00:35:42] <alus> The_8472: if I'm writing a udp proxy to a webserver, I would certainly prefer a memcpy to a bdecode and form an http request and hope I passed everything right
[00:36:18] <The_8472> nobody is going to do that though
[00:36:26] <alus> sure they are
[00:36:47] <alus> this protocol offers crypto, too
[00:37:27] <The_8472> if you write an udp proxy you can just write a tracker in C/C++/python/whatever
[00:37:42] <alus> if you want to rewrite all your DB logic
[00:37:50] <A9> alus: May I PM you?
[00:37:54] <alus> sure
[00:38:23] <alus> a single simple udp proxy can work for everyone
[00:38:59] <The_8472> well, somehow i simply can't see that happening
[00:39:11] <alus> I'll write it myself :P
[00:39:39] <The_8472> won't change a thing
[00:39:48] <The_8472> most php trackers will probably stick to http-tcp only
[00:40:45] <The_8472> and the others aren't using "proper" http anyway and could care less about http parsing
[00:40:57] <The_8472> namely opentracker
[00:41:11] <alus> opentracker certainly does not have a bdecoder
[00:41:42] <The_8472> they don't have a real http decoder either
[00:41:53] <alus> and since it implements pseudo-http parsing, pluggin in udp is a snap
[00:42:24] <The_8472> maybe, but there's no need to use http over udp
[00:42:34] <alus> there's no need to not use it, though
[00:43:16] <alus> and since it makes the upgrade path easier, I think it's a better idea than some shiny new protocol with shiny new bugs
[00:43:44] <The_8472> <alus> there's no need to not use it, though <- being an ugly ugly protocol is...
[00:44:01] <alus> ugly ugly and known.
[00:44:44] <alus> you can always make UDP v3 which looks cleaner. no one will implement it if there are not any benefits, though
[00:45:05] <alus> which is the same reason we have the same old junk we've been using since Bram wrote it
[00:45:31] <Nolar> imho anybody needing real scalabality (opentracker) will be custom writing their own stuff anyway, as everyone else will just stick with http
[00:45:59] <alus> I think the crypto is a big enough of a win that people will use it just for that
[00:46:06] <Nolar> so udp+http doesnt bother me too much
[00:46:23] <alus> location change, bbiab
[00:46:40] <The_8472> the point is: those who can do "proper" http can't really do udp easily. for those who do udp easily HTTP is just a clutch they only use half-heartedly
[00:46:51] *** ProperNoun has quit IRC
[00:46:56] <The_8472> neither group really benefits from http-over-udp
[00:47:51] <Nolar> but the advantage is you can share the same backend parser
[00:49:08] <The_8472> well, there already are 2 code paths anyway... one for http and one for the currnet udp protocl
[00:49:12] <The_8472> *protocol
[00:53:51] *** kwinz2 has joined #bittorrent
[00:56:33] <The_8472> ok. let me put it this way: http is a protcol with a lot of baggage. we know that people won't implement it properly. so why specify a protocol when we have to guess what will be available later on
[00:56:55] <The_8472> bencoding is a trivial spec that most people support reasonably well
[00:58:25] *** ProperNoun has joined #bittorrent
[00:59:49] <The_8472> specifying small, separate building blocks seems to work a lot better than one big does-it-all thing
[01:00:31] <mpl> indeed. even though my client isn't finished and my bdecoding is ugly, it seems to be working...
[01:00:32] <The_8472> 1 spec for crypto, 1 for bencoding, 1 for tracker-over-bencoded-udp
[01:05:23] *** The_8472 has quit IRC
[01:05:45] *** The_8472 has joined #bittorrent
[01:06:27] <The_8472> oO i saw myself quit
[01:09:24] <TheSHAD0W> Heh.
[01:09:27] <TheSHAD0W> Interesting.
[01:35:19] *** danohuiginn has joined #bittorrent
[01:37:46] *** bramm has joined #bittorrent
[01:38:03] * bramm pokes erdgeist
[01:38:13] <TheSHAD0W> Hi Bram.
[01:38:38] <bramm> hey shadow
[01:38:50] <TheSHAD0W> How goes it?
[01:39:03] <bramm> it goes okay, I'm debugging and need a nap
[01:39:23] <TheSHAD0W> Mmm...
[01:39:26] <TheSHAD0W> I can't take naps.
[01:39:32] <TheSHAD0W> I wake up 6 hours later.
[01:39:48] <TheSHAD0W> "Okay, it's the middle of the night, now what do I do?"
[01:41:32] <bramm> I can nap during the day fairly well, the problem is there are kids running around
[01:41:57] <TheSHAD0W> Ahh.  Living, breathing, shrieking alarm clocks.
[01:43:29] *** neurodrone has quit IRC
[01:43:39] *** chelz has joined #bittorrent
[01:44:34] *** senex has joined #bittorrent
[01:52:35] *** ajaya has quit IRC
[01:57:53] <alus> The_8472: I would rather not have two code paths. our udp tracker code path has bugs the other path does not
[02:17:48] *** kwinz2 has quit IRC
[02:33:49] *** kwinz2 has joined #bittorrent
[02:44:59] *** kwinz2 has quit IRC
[02:47:12] *** lioux has joined #bittorrent
[03:00:12] <The_8472> alus, i stand by my point. any spec that requires you to implement http is just asking for improper implementations
[03:00:40] <The_8472> In protocol design, perfection has been reached not when there
[03:00:40] <The_8472> Read more: http://www.faqs.org/rfcs/rfc1925.html#ixzz0fHcItzzJ
[03:00:49] <The_8472> meh
[03:01:05] <The_8472> you know the perfection one ^^
[03:01:35] <alus> yes, some people are going to make normal http mistakes, which everyone is familiar with.
[03:02:33] <The_8472> ...
[03:02:38] <The_8472> you're entirely missing the point
[03:05:17] <alus> what is your point?
[03:08:44] <The_8472> needless complexity (to the point that you KNOW that people will ignore the spec), lack of elegance, questionable benefit, ...
[03:09:01] <The_8472> better alternatives
[03:09:03] *** r2wj has quit IRC
[03:09:37] <The_8472> all in all i don't see how you can be so convinced of your spec
[03:10:35] <alus> it's a very minimal change over the current situation
[03:10:53] <The_8472> i question that
[03:10:53] <alus> the most minimimal possible while achieving the goals
[03:10:59] <The_8472> since udp is not a stream transport
[03:11:09] <The_8472> and http is anything but "minimal"
[03:11:13] <alus> requests and responses can fit in a single packet
[03:11:19] <The_8472> scrapes.
[03:11:21] <alus> I said minimal change
[03:11:49] <alus> scrapes can be broken up into many requests
[03:11:53] *** chelz has quit IRC
[03:12:25] <The_8472> sure, but i wouldn't consider that a minimal change in the sense that you can just plug it in and it works
[03:12:55] <alus> in the case of opentracker you can
[03:13:07] <alus> in the case of uTP you basically can
[03:13:09] <alus> er
[03:13:11] <alus> uTorrent
[03:13:15] * alus has uTP on the brain
[03:14:02] <alus> any questions about protocol are answered the same as the old situation
[03:14:14] <alus> it's a transport change, because all that needed to be changed was the transport
[03:14:45] <alus> hey, just like uTP! look at that
[03:14:59] <The_8472> except that http is designed to run over tcp
[03:15:16] <alus> if you start thinking about how to change the protocol at the same time, you end up making more changes, and have more room for error and confusion
[03:15:25] <The_8472> you do a request and don't have to worry if the response could possibly fit into a single packet or not
[03:15:44] <The_8472> that's why you split things into simple building blocks
[03:15:47] <alus> see: UDP v1, libswift, etc
[03:16:10] <bramm> http has this handy redirect for unavailability with redirect error code, which handles the 'doesn't fit it a packet' response problem nicely
[03:16:22] <alus> you could redirect to tcp, yes
[03:16:24] <The_8472> except that nobody handles it properly
[03:16:37] <alus> we do
[03:16:37] <bramm> uh ... we can handle it properly
[03:16:55] <alus> and all these authors using standard http libraries you keep talking about probably do too
[03:16:59] <alus> including yourself, I imagine
[03:17:06] <The_8472> not too long ago we had someone here complaining about bt clients not supporting redirects
[03:17:20] <The_8472> yes, we sortof handle it
[03:17:28] <alus> mainline should handle it too
[03:17:44] <alus> I think what people don't like is that clients don't record the redirect url for that one status code where you're supposed to do that
[03:18:03] <alus> not a big deal, imho, but some people can't handle DNS I guess
[03:18:21] <The_8472> ahh, it was not handling 404
[03:18:51] <The_8472> and not persisting the redirects, yeah
[03:19:27] <alus> which client didn't handle 404?
[03:21:04] <The_8472> no idea, he didn't say
[03:24:35] <The_8472> well, even if you say that it's a minimal approach by "just" changing the transports then there's still the point that HTTP is needlessly complex and shouldn't have been used in the first place and now there would be an opportunity to do away with it
[03:25:00] *** lioux has quit IRC
[03:26:41] <The_8472> but you seem to be convinced of your idea
[03:26:47] <The_8472> so i'll leave it be and just go to bed
[03:26:51] <The_8472> gn everyone
[03:28:45] <alus> gn
[03:34:18] *** r2wj has joined #bittorrent
[03:37:33] <bramm> there are a lot of very tangible benefits to using http with different transport. Support for it can be added to web servers, and then scripts can be upgraded by simply upgrading the web server
[03:38:09] <bramm> also, I don't really agree that http is needlessly complex, especially the super-minimal subset of it which a single request/response protocol uses
[03:39:29] <bramm> the main potential benefit of a different protocol is more compact encoding, but with the 'compact' key that's already mostly taken care of
[03:51:47] <alus> bramm: did you see my proxy idea?
[03:52:00] <alus> instead of modifying webservers, let's just write a tiny proxy
[03:52:16] <bramm> oh, yeah, that works too
[03:52:31] <alus> then all webservers Just Work. if you want additional performance benefits, you can do more work
[03:53:00] <alus> but I suspect the benefit of not keeping the TCP connections open will already be an improvement
[03:53:25] <bramm> yeah, at least that avoids kernel limits
[03:53:43] <bramm> and it gets the encryption benefits without the crippling effect of https
[03:54:08] <bramm> I'm kinda hazy on why https is such a disaster, actually - in principle it shouldn't be too bad
[03:55:42] <alus> a disaster? I think it's only bad because of the extra roundtrip
[03:56:11] <bramm> erdgeist indicated it can only handle about 1% the number of requests
[03:57:04] <alus> erdgeist: can you explain that? what happened with https? did you just use SSL sockets and do your own implementation?
[03:57:11] <alus> erdgeist: did it eat all your cpu?
[03:58:55] <bramm> he covered it at the conference
[03:59:16] <alus> I forgot
[03:59:16] <bramm> and he's been idle the last day and a half, so he probably won't answer any questions for a while
[03:59:27] <alus> do you remember?
[04:00:01] <bramm> I remember specifically that he said opentracker gets 1% the throughput using https
[04:00:10] <alus> yes but why
[04:00:13] <DeHackEd> need an ssl offloader
[04:00:21] <bramm> I'm not sure
[04:00:32] * alus sighs
[04:00:32] <alus> http://www.kohala.com/start/ttcp.html
[04:00:33] <bramm> I suspect that it's in ssl (duuuuuh)
[04:00:40] <DeHackEd> ssl overhead is brutal, but that still seems kinda high
[04:01:09] <bramm> it may not have been well optimized, he might have used some default out of the box settings
[04:01:30] <bramm> but still, I suspect his big problem is CPU overhead, and those PK handshakes are gonna be brutal no matter what
[04:01:36] <alus> yeah
[04:01:42] <bramm> that's why I want to take RSA seriously as a possibility
[04:01:46] <alus> :(
[04:01:51] *** The_8472 has quit IRC
[04:01:53] <DeHackEd> I've done benchmarks with openssl. private key operations are horrid.
[04:01:54] <alus> but it is not sexy
[04:02:23] <alus> curve25519 is sexy
[04:02:38] <bramm> yes, but I'm doing engineering, not making pornography
[04:02:55] <alus> perhaps this is your mistake!
[04:03:08] <bramm> I may yet use curve25519, need some real data before rendering judgement
[04:03:17] <alus> yes, benchmarking!
[04:03:25] <alus> http://code.google.com/p/curve25519-donna/
[04:03:44] 
[04:04:02] *** senex has quit IRC
[04:04:29] <bramm> djb is a weird dude
[04:06:01] *** The_8472 has joined #bittorrent
[04:06:53] <bramm> 200us is 5000 operations/second
[04:09:21] <bramm> RSA-1024 can get about three times that many encryptions done
[04:10:09] <bramm> (assuming that it's comparable hardware in the benchmarks I'm reading, but the cycles/operation indicate a similar ratio)
[04:13:24] <DeHackEd> that's about right
[04:15:46] *** GabydeWilde__ has joined #bittorrent
[04:16:37] *** GabydeWilde_ has quit IRC
[04:17:02] <bramm> RSA2048 is about half the speed, although that's still faster and it has a much more ridiculous effective key length than curve22519
[04:17:38] <bramm> truth be known rsa-1024 is kinda ridiculous for this use case on its own
[04:30:02] *** edigaryev has joined #bittorrent
[04:40:46] *** senex has joined #bittorrent
[05:04:25] *** danohuiginn has quit IRC
[05:04:31] *** goussx has quit IRC
[05:04:38] *** Vox_456 has joined #bittorrent
[05:04:51] *** Vox_456 has left #bittorrent
[05:16:21] *** burris has quit IRC
[05:31:54] *** ivan` has quit IRC
[05:32:01] *** ivan` has joined #bittorrent
[05:32:39] *** ivan` has quit IRC
[05:32:55] *** ivan` has joined #bittorrent
[05:40:33] *** init0 has quit IRC
[05:42:38] *** init0 has joined #bittorrent
[05:45:01] *** goussx has joined #bittorrent
[06:13:12] *** MassaRoddel has quit IRC
[06:20:57] *** mchang has joined #bittorrent
[06:21:29] <mchang> greetings. anyone about?
[06:33:25] <alus> perhaps
[06:34:06] *** mchang has quit IRC
[06:44:35] *** KyleK_ has joined #bittorrent
[06:50:00] *** charles has quit IRC
[06:50:00] *** charles has joined #bittorrent
[06:50:31] *** KyleK_ has quit IRC
[06:50:54] *** Gottaname has quit IRC
[06:51:03] *** Gottaname has joined #bittorrent
[07:00:53] *** void^_ has quit IRC
[07:13:30] *** MassaRoddel has joined #bittorrent
[07:27:20] *** chelz has joined #bittorrent
[07:33:31] *** edigaryev has quit IRC
[07:37:02] *** burris has joined #bittorrent
[07:38:26] *** senex has quit IRC
[07:41:41] *** senex has joined #bittorrent
[08:14:50] *** bramm has quit IRC
[08:38:30] *** GTHK has quit IRC
[08:46:42] *** senex has quit IRC
[09:01:34] *** danohuiginn has joined #bittorrent
[09:54:29] *** lsdeviant has joined #bittorrent
[10:02:53] *** kwinz2 has joined #bittorrent
[10:12:53] *** senex has joined #bittorrent
[10:16:53] *** Switeck has quit IRC
[10:30:24] *** danohuiginn has quit IRC
[10:52:54] *** danohuiginn has joined #bittorrent
[10:54:56] *** kwinz2 has quit IRC
[11:09:14] <lsdeviant> is there anything better than BitTorrent?
[11:10:00] <kjetilho> of course not
[11:10:29] <lsdeviant> i mean when do we get to see intelligence built into the protocol like being able to priotize seeders based on a preference
[11:10:50] <kjetilho> that's not intelligence
[11:10:53] *** jamie_k has joined #bittorrent
[11:11:12] <lsdeviant> intelligence would be not having to think about it
[11:11:19] <lsdeviant> :) but it's a step toward that
[11:11:51] <lsdeviant> i want my client to connect to the seeders with the best rate for example
[11:12:34] <lsdeviant> for a torrent with 30,000 seeds, the chances of getting a good upstream is pretty random, correct?
[11:12:47] <lsdeviant> or can someone school me
[11:17:22] <kjetilho> so why should *you* get the best seeds?
[11:18:48] <lsdeviant> because i have a higher upstream
[11:18:51] <lsdeviant> :)
[11:19:01] <lsdeviant> the faster i get it, the faster everyone else gets it
[11:19:15] <lsdeviant> at least thats the simple logic my brain is telling me, which i realize could be flawed
[11:19:33] <chelz> assuming you stay on and also assuming there's some un-forge-able way you report your upstream
[11:19:53] <lsdeviant> exactly why i asked if there was anything better
[11:20:00] <lsdeviant> that is a protocol enhancement for sure
[11:20:04] <chelz> eh better is subjective
[11:20:10] <chelz> BT seems to work for a lot of people
[11:20:25] <kjetilho> over time, seeds will locate you and prefer to send to you
[11:20:36] *** _rafi_ has joined #bittorrent
[11:21:38] <lsdeviant> it works great for me.  but lets be honest, can it be improved?  i think so
[11:22:28] <DreadWingKnight> it can be improved, but what you're looking at isn't where the improvements need to be
[11:22:36] <lsdeviant> perhaps making the protocol "extensible" for trackers that opt to use a certain enhancement to meet goals of their user base
[11:22:57] <mpl> lsdeviant: some of the behaviour you describe is already there.
[11:24:25] <lsdeviant> DreadWingKnight:  where do you think they ought to be?
[11:24:52] <DreadWingKnight> in dealing with the throttling problems that most ISPs introduce to the matter
[11:25:12] <DreadWingKnight> [6:19:44am] <kjetilho> so why should *you* get the best seeds?
[11:25:13] <DreadWingKnight> [6:21:10am] <lsdeviant> because i have a higher upstream
[11:25:19] <DreadWingKnight> seeds don't care about your upstream
[11:25:22] <DreadWingKnight> other downloaders do
[11:25:30] <DreadWingKnight> and if you're smart about how you set your client up
[11:25:46] <DreadWingKnight> you get good piece trade relationships going with those downloaders
[11:25:49] *** kwinz2 has joined #bittorrent
[11:25:56] <DreadWingKnight> and get better speeds than if you had of connected to all seeds
[11:26:04] *** mxs_ has joined #bittorrent
[11:26:04] *** mxs has quit IRC
[11:26:04] *** mxs_ has quit IRC
[11:26:04] *** mxs_ has joined #bittorrent
[11:26:09] <lsdeviant> interesting...
[11:26:10] *** mxs_ is now known as mxs
[11:26:19] <lsdeviant> is this a big secret of yours or should i do some homework
[11:26:49] <DreadWingKnight> it's the way the core of the protocol works
[11:27:11] <DreadWingKnight> seeds have no incentive to upload to you because they don't want anything you have
[11:27:33] <lsdeviant> i kind of get what you're saying but i'm not knowledgeable about how a "relationship" is maintained amongst what you'd call optimal peers
[11:27:36] <DreadWingKnight> other downloaders likely DO want stuff you have, so they would likely want to upload to you stuff you want
[11:29:39] <lsdeviant> see, i didn't realize that your client could choose to connect to someone based on some metadata like that
[11:29:46] <lsdeviant> i'm still learning :)
[11:29:55] <DreadWingKnight> you don't choose to connect from that information
[11:30:03] <DreadWingKnight> you choose to UPLOAD from that information
[11:30:40] <DreadWingKnight> you connect to the peers you obtain from the tracker peerlist (which is random), DHT (which is also random) and peer exchange (which is neighbors of neighbors)
[11:30:50] <lsdeviant> i see... that makes more sense
[11:31:31] <lsdeviant> yeah i understand the basics but just not the way your client can prefer a certain peer.  but now i do
[11:34:06] <lsdeviant> on another topic, do you think OneSwarm is the best approach to privacy?
[11:34:29] <lsdeviant> again best is subjective but consider best to mean useable for a very broad user base
[11:37:22] <DreadWingKnight> social engineering actually makes it very bad
[11:38:36] <lsdeviant> as in, you can't keep the bad guys out
[11:38:47] <lsdeviant> since theyre not really traceable?
[11:39:00] <chelz> well social engineering is also a weakness in Tor
[11:42:54] *** kwinz2 has quit IRC
[11:54:10] *** punto has quit IRC
[11:59:14] *** kwinz2 has joined #bittorrent
[12:01:50] *** lsdeviant has quit IRC
[12:04:28] *** fucnqshun has joined #bittorrent
[12:04:47] <fucnqshun> is there a rapidshare channel somewhere?
[12:05:00] <DreadWingKnight> why should we care if there is?
[12:05:33] *** punto has joined #bittorrent
[12:06:04] <fucnqshun> that doesnt answer my question
[12:06:34] <DreadWingKnight> you think I care?
[12:06:37] <chelz> you could try rapidshare support on their site
[12:06:59] <chelz> that's probably the closest equivalent to rapidshare what this channel is is for bittorrent
[12:09:24] *** kwinz2 has quit IRC
[12:09:54] *** fucnqshun has quit IRC
[12:14:35] *** cgreco has quit IRC
[12:14:40] *** cgreco has joined #bittorrent
[12:14:41] *** cgreco has joined #bittorrent
[12:14:57] *** punto has quit IRC
[12:18:44] *** senex has quit IRC
[12:25:17] <erdgeist> alus: back again
[12:26:24] *** edigaryev has joined #bittorrent
[12:35:12] *** kwinz2 has joined #bittorrent
[12:35:20] *** punto has joined #bittorrent
[12:41:09] *** punto has quit IRC
[12:42:14] *** punto has joined #bittorrent
[12:46:36] *** punto has quit IRC
[12:58:23] *** punto has joined #bittorrent
[13:12:33] *** danohuiginn has quit IRC
[13:31:43] <The_8472> alus, for the udp proxy... you're forgetting about the source IP which is used by trackers. so you'd have to fudge at least something
[13:32:06] <The_8472> not to mention that you still would do tons of tcp connections, just over the loopback interface instead of a real network card
[13:32:45] <The_8472> and since you still need a 3way handshake (and maybe encryption handshake) with UDP you need to design a transport layer between udp and http
[13:32:52] <The_8472> so you're already designing your own protocol anyway
[13:34:36] *** cyb2063 has joined #bittorrent
[13:46:17] *** danohuiginn has joined #bittorrent
[13:55:25] <erdgeist> alus: there is many problems with ssl, first: the obvious crypto overhead, quickly using CPU that the OS would rather spend in handling tcp, second: protocol data overhead, the amount of packets required more than doubles, leading to more tcp connections in an open state
[13:57:55] <erdgeist> alus: and all the measurements showing how quick the crypto algorithms are, are only half true: if they're executed in a loop. If you do it only once per connection, with a lot of other code thrashing caches inbetween, you can nearly double the time spent in RSA and curve25519
[14:06:07] *** rot has joined #bittorrent
[14:10:16] <The_8472> erdgeist, in a very high throughput scenario you could feed 1 thread doing the crypto through 2 asynchronous queues
[14:10:47] <The_8472> and bind it to one core
[14:12:44] <The_8472> though you need some decent lock-free data structures to pull that off
[14:12:54] <erdgeist> and convince openssl to do that
[14:13:24] <The_8472> well, i meant if you want to roll your own ^^
[14:13:57] <erdgeist> Then I'd rather split it between two machines sharing one secret
[14:14:00] <erdgeist> ;)
[14:14:42] *** _rafi_ has quit IRC
[14:15:09] *** _rafi_ has joined #bittorrent
[14:15:31] <The_8472> if you go for 2 machines you could split the decrypting stage and the tracker logic between them
[14:15:35] *** _rafi_ has quit IRC
[14:15:38] <The_8472> and use different CPUs on each
[14:15:59] *** _rafi_ has joined #bittorrent
[14:16:52] *** _rafi_ has quit IRC
[14:21:26] *** _rafi_ has joined #bittorrent
[14:32:10] *** punto has quit IRC
[14:32:47] *** r2wj has quit IRC
[14:33:22] *** r2wj has joined #bittorrent
[14:41:14] *** punto has joined #bittorrent
[14:45:56] *** kwinz2 has quit IRC
[14:59:01] *** void^ has joined #bittorrent
[15:00:33] *** _rafi_ has quit IRC
[15:04:04] *** _rafi_ has joined #bittorrent
[15:08:24] *** The_8472 has quit IRC
[15:09:46] *** kwinz2 has joined #bittorrent
[15:12:50] *** _rafi_ has quit IRC
[15:13:17] *** The_8472 has joined #bittorrent
[15:16:58] *** _rafi_ has joined #bittorrent
[15:30:16] *** danohuiginn has quit IRC
[15:36:37] *** chelz has quit IRC
[16:46:30] *** davidoe has joined #bittorrent
[17:07:20] *** danohuiginn has joined #bittorrent
[17:26:10] *** _rafi_ has quit IRC
[17:26:18] <alus> The_8472: inserting an HTTP header is not so bad. and you do not need the internal TCP connections open for as long - once you read the response you can close, they don't need to sit in TIME_WAIT
[17:30:09] *** _rafi_ has joined #bittorrent
[17:38:49] *** Andrius has joined #bittorrent
[17:45:01] *** KyleK_ has joined #bittorrent
[18:00:29] *** cyb2063 has quit IRC
[18:20:44] *** r2wj has quit IRC
[18:22:04] *** GabydeWilde__ is now known as GabydeWilde_
[18:25:09] *** goussx has quit IRC
[18:38:15] *** ProperNoun has quit IRC
[18:40:01] *** ProperNoun has joined #bittorrent
[18:54:28] *** goussx has joined #bittorrent
[19:20:13] *** danohuiginn has quit IRC
[19:29:59] *** GTHK has joined #bittorrent
[21:10:52] *** GTHK has quit IRC
[21:12:56] *** GTHK has joined #bittorrent
[21:39:20] *** Switeck has joined #bittorrent
[21:42:41] *** edigaryev has quit IRC
[22:12:20] *** lsdeviant has joined #bittorrent
[22:24:46] *** lsdeviant has quit IRC
[22:48:04] *** jamie_k has quit IRC
[23:00:20] *** davidoe has quit IRC
[23:13:52] *** neurodrone has joined #bittorrent
[23:18:54] *** neurodrone has quit IRC
[23:19:18] *** neurodrone has joined #bittorrent
[23:37:27] *** jamie_k has joined #bittorrent
[23:46:27] *** jamie_k has quit IRC
[23:50:44] *** ajaya has joined #bittorrent
[23:53:10] *** jamie_k has joined #bittorrent
[23:56:39] *** danohuiginn has joined #bittorrent
[23:57:44] *** Andrius has quit IRC





top