[00:09:33] *** mpl has quit IRC
[00:09:36] *** mpl has joined #bittorrent
[00:18:11] *** Elrohir has quit IRC
[00:23:03] *** ProperNoun has joined #bittorrent
[00:38:23] *** ProperNoun has quit IRC
[00:43:01] *** ProperNoun has joined #bittorrent
[00:53:42] *** BlackDog123 has joined #bittorrent
[00:55:52] <BlackDog123> Please,Someone can seed?
[00:56:07] <Switeck> no
[00:57:50] <BlackDog123> Seed Borat, a funny movie?
[00:57:57] <TheSHAD0W> 9_9
[00:59:07] <TheSHAD0W> DeHackEd?
[00:59:12] <TheSHAD0W> We have a customer...
[00:59:32] <Switeck> let it die!
[01:00:01] <The_8472> fascinating how they know so little and yet find their way here
[01:04:08] <mpl> random mouse clicks can do wonders nowadays.
[01:04:57] * The_8472 fears the day when a toddler can create grey goo by randomly hitting keys on a kitchen appliance
[01:05:25] <The_8472> toddler or clueless user
[01:08:48] *** Andrius has quit IRC
[01:09:04] <BlackDog123> Anyone knows alternatives to ThePirateBay?
[01:09:18] <mpl> speaking of clueless, I can't figure out why when i'm connecting to a peer all goes fine (sending my handshake, receiving its, etc...), while when I'm listening, the peer connects, sends the handshake _without its peer_id, and then does nothing else, even after I send my handshake.
[01:10:11] <mpl> what would be the reason for a peer to send only the first 48 bytes of its handshake?
[01:11:09] <The_8472> port probing you maybe?
[01:11:12] <The_8472> some trackers do that
[01:11:12] <Switeck> hostile ISP?
[01:11:18] <The_8472> check the source address
[01:11:24] <mpl> BlackDog123: yes, Ilovetheriaa.com is a good one.
[01:11:43] <mpl> oh everything is running on locally
[01:11:44] <BlackDog123> Thanks mpl
[01:11:58] <kjetilho> I prefer warez.fbi.gov
[01:12:12] <mpl> the other peer is mainline, and I'm also running the tracker locally.
[01:14:01] <mpl> bleh, I'm so frustrated to still run into that kind of problems while the protocol seems so simple when you read it.
[01:14:58] <Switeck> mainline? I thought those died off
[01:14:59] <mpl> took me long enough to figure things out right when I was the connecting one and now it's the same struggle for the other way around.
[01:15:22] <mpl> Switeck: I'm running it locally as a test peer.
[01:15:47] <Switeck> BitTorrent the rebranded uTorrent client or pre-uTorrent BitTorrent client?
[01:18:02] <mpl> bleh, no -v or --version, lemme check the package
[01:19:07] <mpl> deb package version is 3.4.2-11.1
[01:19:49] <mpl> dunno when that was compared to microtorrent.
[01:19:57] *** senex has joined #bittorrent
[01:20:45] <Switeck> then it's not uTorrent
[01:20:52] <BlackDog123> Is usenet more fast than torrent?
[01:21:15] <Switeck> I thought it was less faster
[01:21:38] <The_8472> mpl, does it send the infohash?
[01:21:45] <mpl> Switeck: no you're wrong it's more fastest. it uses golden fiber, remember?
[01:21:46] <Switeck> if the file isn't on usenet, can't exactly be fast...
[01:22:01] <mpl> The_8472: yep
[01:22:18] <The_8472> and you're replying with the infohash too?
[01:22:32] <mpl> yep, replying the full handshake
[01:22:38] <The_8472> hrrm...
[01:22:44] <BlackDog123> I have seen a lot of sites that tell that the usenet is the best way to get warez.
[01:22:46] <Switeck> odd that peer doesn't disconnect.
[01:23:27] <The_8472> well, i guess you could wireshark the connection between two mainline clients
[01:23:31] <The_8472> and then compare to yours
[01:23:57] <mpl> oh don't get me wrong, mainline is probably not at fault, since rtorrent seems to behave the same.
[01:24:10] <mpl> but I just don't know what I could possibly be doing wrong this time.
[01:24:38] <The_8472> yes.... that's why i suggested comparing wireshark logs of a working and a non-working connection
[01:24:42] *** BlackDog123 has quit IRC
[01:24:45] <mpl> The_8472: I'm tcpdumping already, that's how I see it only sends 48 bytes instead of 68 for the handshake.
[01:25:05] <mpl> hmm ok
[01:25:21] <mpl> with 2 mainline then, good suggestion, thx.
[01:37:11] *** Miller` has quit IRC
[01:40:11] *** Miller` has joined #bittorrent
[01:56:31] <mpl> meh, I've just discovered the vuze wiki, it holds way more info than the wikitheory page...
[02:26:10] *** goussx has joined #bittorrent
[02:30:56] *** Miller` has quit IRC
[02:38:08] *** wojci has quit IRC
[02:38:16] *** KyleK_ has quit IRC
[02:54:16] *** wojci has joined #bittorrent
[02:57:07] *** ProperNoun has quit IRC
[03:06:57] *** dulop has joined #bittorrent
[03:20:22] *** uau has quit IRC
[03:20:40] *** uau has joined #bittorrent
[03:22:35] *** init0 has quit IRC
[03:26:22] *** init0 has joined #bittorrent
[03:46:20] *** chelz has quit IRC
[03:52:59] *** Harold_parker has quit IRC
[04:01:05] *** The_8472 has quit IRC
[04:06:04] *** The_8472 has joined #bittorrent
[04:41:43] <scottwolchok> uTorrent DHT is just mainline, not a separate DHT, right?
[04:42:09] <The_8472> yes
[04:43:20] <scottwolchok> mmkay
[04:48:46] *** goussx has quit IRC
[04:49:41] *** goussx has joined #bittorrent
[05:00:18] *** senex has quit IRC
[05:15:53] *** dulop has quit IRC
[05:19:40] *** GTHK has quit IRC
[05:29:52] *** goussx has quit IRC
[05:31:22] *** Miller` has joined #bittorrent
[05:40:29] *** init0 has quit IRC
[05:42:26] *** init0 has joined #bittorrent
[05:48:12] *** ProperNoun has joined #bittorrent
[05:55:37] *** ProperNoun has quit IRC
[05:58:05] *** neurodrone has quit IRC
[06:02:28] *** ProperNoun has joined #bittorrent
[06:09:02] *** bittwist has joined #bittorrent
[06:13:04] *** bt42 has quit IRC
[06:13:43] *** S7ra4e is now known as SeanNoble
[06:51:27] *** MassaRoddel has quit IRC
[07:15:22] *** r2wj has quit IRC
[07:16:56] *** Switeck has quit IRC
[07:25:29] *** senex has joined #bittorrent
[07:28:06] *** goussx has joined #bittorrent
[07:28:08] *** Smushers has joined #bittorrent
[07:29:16] *** edigaryev has joined #bittorrent
[07:29:35] *** Smushface has joined #bittorrent
[07:32:59] *** Smushers has quit IRC
[07:33:37] *** Smushface is now known as Smushers
[08:30:03] *** _rafi_ has joined #bittorrent
[08:51:40] *** r2wj has joined #bittorrent
[09:12:08] *** chelz has joined #bittorrent
[09:33:25] *** Andrius has joined #bittorrent
[09:46:07] *** MassaRoddel has joined #bittorrent
[10:09:32] *** senex has quit IRC
[10:12:58] *** chelz has quit IRC
[11:28:54] *** ryanprior has quit IRC
[11:30:19] *** mxs has joined #bittorrent
[11:30:19] *** mxs has joined #bittorrent
[11:45:06] *** flc has joined #bittorrent
[11:45:26] <flc> any reason why bittorrent doesn't use udp?
[11:45:35] <flc> (for file transfers)
[11:49:25] <kjetilho> flc: reimplementing TCP on top of UDP generally performs worse
[11:49:54] <flc> kjetilho: why would anyone do THAT?
[11:49:55] <kjetilho> UDP makes sense on a LAN, or when you don't worry about lost packets too much
[11:50:14] *** KyleK_ has joined #bittorrent
[11:50:35] <kjetilho> for BitTorrent, you need both reliable transfer and congestion control
[11:51:01] <flc> kjetilho: for one, you don't need the packets to arrive in the same order they were sent
[11:51:12] <kjetilho> TCP doesn't require that, either
[11:51:27] <flc> kjetilho: but it keeps track of the order, right?
[11:51:37] <kjetilho> sure, but BitTorrent needs that
[11:51:43] <flc> kjetilho: why?
[11:51:50] <kjetilho> unless you use a piece size of 1500 bytes :)
[11:52:10] <kjetilho> 2 MB is way outside IP limits
[11:53:40] <flc> kjetilho: you can do a multiple of 1500 and a 4 or 5-bit id inside that chunk
[11:54:12] <kjetilho> that's not very different from TCP, is it?
[11:54:19] <kjetilho> and how do you do ACK?
[11:54:41] <kjetilho> or should I say NAK?
[11:55:01] <kjetilho> rely on timeouts?  not a good way to get throughput
[11:55:30] <kjetilho> seriously, TCP is very efficient
[11:55:59] <flc> kjetilho: you can handle the data as a lossy stream and just re-request the missing chunks
[11:56:36] <flc> kjetilho: that would rid you of the necessity to send acks at all
[11:56:44] <kjetilho> that will use a lot more bandwidth than TCP's ACK
[11:56:49] <kjetilho> ACK is piggybacked
[11:57:17] <kjetilho> (if you're exchanging data with your peer, which is quite common)
[11:57:19] <flc> kjetilho: but I don't think the client needs to explicitly request any more data at all
[11:57:31] <flc> kjetilho: let the server just send the packets
[11:57:44] <kjetilho> "the server"?
[11:57:52] <kjetilho> so you're not talking about P2P?
[11:57:53] <flc> kjetilho: the peer who sends...
[11:58:02] <kjetilho> send what?
[11:58:07] <DWKnight> http://bittorrent.org/beps/bep_0029.html
[11:58:09] <flc> hmm, the data
[11:58:17] <kjetilho> all data?
[11:58:51] <flc> kjetilho: I'm talking about a single socket connection. one of the peers is on the sending end, the other on the receiving end
[11:59:28] <flc> they are usually called client/server, but maybe BT has a different naming
[12:00:00] <DWKnight> flc, to your original question at 13 to the hour
[12:00:01] <DWKnight> http://bittorrent.org/beps/bep_0029.html
[12:00:28] <flc> DWKnight: yes. is it implemented already?
[12:00:39] <kjetilho> ... which is essentially reimplementing TCP, and is less efficient
[12:00:40] <DWKnight> not widespread yet
[12:00:58] <flc> DWKnight: do you know what utorrent version implements it?
[12:01:10] <flc> I have 2.0 here, and there are no UDP connections in netstat
[12:01:24] <kjetilho> flc: the P stands for peer -- there is no server-client relationship
[12:02:25] <flc> kjetilho: I know. it's just handy to call things by the usual names, instead of saying "the peer who sends" and "the peer who receives" all the time
[12:03:04] <DWKnight> peers tab, "P" flag flc
[12:03:29] <kjetilho> sure, muddle up terminology all you want, it's a good way to enhance communication</sarcasm>
[12:04:05] <flc> DWKnight: utorrent puts [uTP] next to a lot of peer hosts, but all of them use TCP. so is it some kind of other uTP that's described in the document?
[12:05:04] <flc> kjetilho: well, I assume you understand the terms I used now
[12:05:05] <DWKnight> if there's a P flag, they're using uTP
[12:05:42] <kjetilho> flc: but your argument is flawed, since the peers are sending data both ways simultaneously
[12:06:02] <flc> DWKnight: how do you explain the lack of UDP connections in netstat, then?
[12:06:47] <DWKnight> udp is connectionless
[12:07:09] <flc> kjetilho: in some cases they are. in others they're not. one example is communication with a seed
[12:08:15] <flc> DWKnight: isn't it supposed to still show the UDP sockets in the accept state?
[12:08:28] <kjetilho> anyway, you have your answer.  using UDP is less efficient for BitTorrent
[12:09:01] <DWKnight> pretty sure it's not
[12:09:14] <DWKnight> you might be able to see them more accurately in tcpview
[12:09:19] <DWKnight> or a similar app
[12:13:34] <flc> DWKnight: yup, wireshark shows a lot of UDP traffic on the utorrent port
[12:14:05] <flc> kjetilho: I guess utorrent is inefficient, then :)
[12:14:22] <kjetilho> yes, the motivation is not efficiency
[12:15:10] <kjetilho> you could say that for a DSL user it is more efficient since it can reach 100% utilisation without impacting other users too badly
[12:15:40] <kjetilho> but the global efficiency of the network is worse
[12:27:53] <alus> kjetilho: why?
[12:28:16] <kjetilho> alus: the overhead per byte sent?
[12:28:28] <alus> kjetilho: why is that higher on UDP than TCP?
[12:28:45] <kjetilho> on BEP-29
[12:30:05] <kjetilho> not a large difference, though
[12:30:33] <alus> or an interesting one - we could have made the headers smaller than TCP
[12:31:08] <alus> overhead is not the problem with BitTorrent
[12:31:27] <kjetilho> agreed
[13:12:07] *** razvand has joined #bittorrent
[13:26:20] <The_8472> <DWKnight> udp is connectionless <- conntrack keeps track of udp pseudo-connections to do the NATing/forwarding/keep state
[13:30:46] <The_8472> but yes, they wouldn't show up in netstat
[14:00:28] *** _rafi_ has quit IRC
[14:06:32] *** _rafi_ has joined #bittorrent
[14:12:53] <alus> The_8472: it can't really tell if one uT client is talking to another client about two torrents.
[14:13:04] <alus> The_8472: uT would call that two connections, conntrack probably wouldn't
[14:21:52] *** stalled has quit IRC
[14:25:01] *** flc has quit IRC
[14:28:35] <The_8472> alus, conntrack considers it a connection as soon as you sent an UDP packet and got a reply on the same socket pair
[14:29:31] <The_8472> so yes, of course 2 torrents could run over 1 "connection"
[14:29:46] <The_8472> but that isn't all that likely
[14:29:59] <The_8472> so in most cases 1 conntrack entry = 1 torrent connection
[14:32:51] <alus> yes. it's correct except when it isn't :P
[14:33:29] <alus> I would say it's trivial to add uTP connection id awareness to conntrack, but I looked at adding uTP parsing awareness to Wireshark and MS Network Monitor
[14:33:32] <alus> what a nightmare.
[14:33:45] <alus> it's harder than implementing the whole protocol
[14:54:24] *** stalled has joined #bittorrent
[15:01:26] *** stalled has quit IRC
[15:03:56] *** stalled has joined #bittorrent
[15:04:53] <The_8472> you could probably just copy the TCP filter for wireshark and modify it
[15:22:58] <alus> I looked at that. it's quite huge, and littered with rarely-used TCP options
[15:23:32] <alus> it is probably the most complicated and messy implementation of TCP there is
[15:32:13] *** _rafi_ has quit IRC
[15:41:42] *** _rafi_ has joined #bittorrent
[15:50:50] <The_8472> heh
[15:51:41] <The_8472> must be sortof like C++ then... the only way to implement a full syntax parser in C is practically implementing a compiler
[15:54:06] <alus> worse I think, because it has to support every option no matter how esoteric and forgotten
[15:54:24] <alus> it's not enough to have a TCP implementation which would work with itself, or even with all other TCP implementations of interest
[16:00:12] <The_8472> well, you could just mark options as unknown or whatever. but yeah, that's not the point of a tool like wireshark
[16:35:33] *** razvand has quit IRC
[16:35:54] *** _rafi_ has quit IRC
[16:40:49] *** _rafi_ has joined #bittorrent
[16:48:28] *** _rafi2_ has joined #bittorrent
[16:50:36] *** _rafi_ has quit IRC
[17:05:34] *** Adjective has joined #bittorrent
[17:09:11] *** ProperNoun has quit IRC
[17:13:20] *** bittwist is now known as ElJesus
[17:13:55] *** ElJesus is now known as bittwist
[17:26:45] *** medz has joined #bittorrent
[17:27:05] *** medz is now known as Davidoe
[17:27:21] *** Davidoe is now known as davidoe
[18:06:23] *** r3wj has joined #bittorrent
[18:09:58] *** r2wj has quit IRC
[18:21:17] *** ProperNoun has joined #bittorrent
[18:23:16] *** Adjective has quit IRC
[18:32:19] *** Smushers has quit IRC
[19:50:19] *** r3wj is now known as r2wj
[20:00:37] *** r3wj has joined #bittorrent
[20:00:37] *** r2wj has quit IRC
[20:00:55] *** r3wj is now known as r2wj
[20:04:37] *** r3wj has joined #bittorrent
[20:05:32] *** r2wj has quit IRC
[20:06:04] *** kwinz2_ has joined #bittorrent
[20:08:23] *** stalled has quit IRC
[20:09:25] *** kwinz2 has quit IRC
[20:13:42] *** edigaryev has quit IRC
[20:19:49] *** stalled has joined #bittorrent
[20:23:57] *** KyleK_ has quit IRC
[20:26:10] *** edigaryev has joined #bittorrent
[20:34:27] *** ProperNoun has quit IRC
[20:37:10] *** GTHK has joined #bittorrent
[20:41:25] *** rot has quit IRC
[20:42:15] *** rot has joined #bittorrent
[20:57:34] *** edigaryev has quit IRC
[21:15:42] *** r2wj has joined #bittorrent
[21:19:12] *** r3wj has quit IRC
[22:08:11] *** PolishPaul has joined #bittorrent
[22:09:48] <PolishPaul> hey guys, i got lots torrents i want to seed, - i've re arranged them on my drive and need to "audit" my torrent software - any ideas on how to go about this efficiently? Other than opening the torrent file and navigating down to each directory?
[22:17:01] <DWKnight> there is no other way really
[22:42:35] *** r2wj has quit IRC
[22:43:02] *** r2wj has joined #bittorrent
[22:45:54] <burris> if you want to hash check a bunch of torrents in a directory, there are command line tools to do so, worst case you write a little script to do it
[23:02:36] *** kwinz2_ has quit IRC
[23:11:03] *** PolishPaul has quit IRC
[23:25:14] *** davidoe has quit IRC
[23:28:07] *** kwinz2 has joined #bittorrent
[23:37:33] *** _rafi2_ has quit IRC





top