[00:00:05] <The_8472> i was thinking you were dealing with routing 200 clients through a gateway
[00:02:01] <mhall> my understanding is that the connections are coming in from an upstream switch router in switch only mode
[00:02:32] <mhall> and getting routed by the downstream switch router, between different vlans naturally, and different subnets, and coincidentally different port blades
[00:02:39] <mhall> which thus results in backplane activity
[00:02:54] <mhall> it's a complex bug, we've had people on it for 3 months so far
[00:03:16] <mhall> i've been put onto it relatively recently
[00:03:48] <mhall> but in my case, my past work was more L4 and L7, and this problem seems to be L1-L4.
[00:04:28] <mhall> however, before this, i wrote an anomaly detector which collects random traffic samples throughout the network and looks for suspicious activity
[00:04:44] <mhall> so i've gotten pretty comfortable working on protocol stack stuff
[00:05:08] *** echelon has joined #bittorrent
[00:05:42] <The_8472> bittorrent can provide you with almost any scenario ^^
[00:05:56] <The_8472> apart from realtime requirements maybe
[00:06:15] <echelon> bittwist
[00:07:29] <The_8472> udp connections, udp packet exchanges (not connections), long-lived tcp flows, short lived ones. high throughput connections, idle ones...
[00:07:47] <The_8472> and being hammered by possibly millions of different IPs over the course of a few hours
[00:08:35] <The_8472> anyway, we probably can't help you with hardware that you know better than us
[00:08:46] <The_8472> but if you want to know anything about BT, shoot
[00:10:29] *** stalled_ has joined #bittorrent
[00:11:06] *** stalled has quit IRC
[00:11:15] *** stalled_ is now known as stalled
[00:11:52] <JudgeSHAD0W> mhall: Some BT clients set low-priority bits for TCP connections, and I've seen that do horrible things to some routers.  That's something you might take a quick look at.
[00:13:59] <The_8472> do routers actually honor them in any way?
[00:15:38] <JudgeSHAD0W> Some try - and fail miserably, apparently.
[00:16:13] <JudgeSHAD0W> I had it set on my client, then disabled it when I got complaints about it.
[00:16:33] <JudgeSHAD0W> I don't recall exactly what happened - bounces, fragmentation...
[00:16:58] *** cyb2063 has quit IRC
[00:17:56] <The_8472> oh, i'm really gambling then. not just setting good old ToS flags but some newer diffserv combinations
[00:28:17] *** Andrius has quit IRC
[00:32:55] *** JudgeSHAD0W has quit IRC
[00:41:29] *** echelog has joined #bittorrent
[00:53:16] <echelon> wtf
[01:03:08] <DeHackEd> ?
[01:04:01] *** echelon has left #bittorrent
[01:28:08] *** andar2 has quit IRC
[01:28:46] *** ajaya has quit IRC
[01:32:03] *** bpot has quit IRC
[01:33:57] *** ajaya has joined #bittorrent
[02:21:18] *** grantmclean has joined #bittorrent
[02:28:52] *** The_8472 has quit IRC
[02:38:29] *** grantmclean has quit IRC
[02:45:10] *** waldorf_ has quit IRC
[03:12:11] *** ajaya_ has joined #bittorrent
[03:19:04] *** ajaya_ has quit IRC
[03:22:21] *** MassaRoddel has quit IRC
[03:22:51] *** ajaya has quit IRC
[03:29:32] *** init0_ has joined #bittorrent
[03:39:49] *** bpot has joined #bittorrent
[03:41:28] *** init0 has quit IRC
[03:50:50] *** rrr has joined #bittorrent
[03:55:06] *** gilles_ has joined #bittorrent
[03:55:57] *** KyleK_ has quit IRC
[04:12:18] *** gilles has quit IRC
[04:12:23] *** gilles_ has quit IRC
[05:04:04] *** mhall has quit IRC
[05:10:25] *** rrr has quit IRC
[05:13:50] *** bittwist has quit IRC
[05:48:07] *** bittwist has joined #bittorrent
[05:57:06] *** TheSHAD0W has quit IRC
[06:02:48] *** TheSHAD0W has joined #bittorrent
[06:07:11] *** gilles has joined #bittorrent
[06:16:39] *** bittwist has quit IRC
[06:20:04] *** bittwist has joined #bittorrent
[06:22:55] *** KyleK_ has joined #bittorrent
[06:46:09] *** bittwist has quit IRC
[06:49:01] *** KyleK_ has quit IRC
[06:49:35] *** bittwist has joined #bittorrent
[07:09:04] *** MassaRoddel has joined #bittorrent
[07:16:25] *** gilles has quit IRC
[07:34:21] *** bittwist has quit IRC
[07:38:24] *** bittwist has joined #bittorrent
[07:41:17] *** bittwist is now known as bt42
[08:22:08] *** Andrius has joined #bittorrent
[08:45:13] *** cyb2063 has joined #bittorrent
[09:08:12] *** spoop has quit IRC
[09:13:26] *** nascentmind has joined #bittorrent
[09:19:20] *** rrr has joined #bittorrent
[09:21:37] *** waldorf_ has joined #bittorrent
[09:32:41] *** nascentmind has quit IRC
[09:38:31] *** The_8472 has joined #bittorrent
[10:17:51] *** cyb2063 has quit IRC
[10:20:20] *** cyb2063 has joined #bittorrent
[10:26:08] *** cyb2063 has quit IRC
[10:26:38] *** cyb2063 has joined #bittorrent
[10:26:56] *** goussx has quit IRC
[10:27:24] *** goussx has joined #bittorrent
[12:36:43] *** init0_ is now known as init0
[14:34:36] *** AnimeBoY has joined #bittorrent
[14:35:15] *** AnimeBoY has left #bittorrent
[15:13:17] *** charles has quit IRC
[15:13:31] *** charles has joined #bittorrent
[15:25:32] *** pevangelista has joined #bittorrent
[15:26:37] <pevangelista> Hello, to all. I have a doubt about how the client manages its connections with other peers. Let me explain...
[15:27:44] <pevangelista> When the client acquires the peer list from the Tracker, it opens a TCP connection with all the peers in this list (or with a subset of this list, capped by a max_connections parameter)
[15:28:36] <pevangelista> Say my client connects with 50 peers and exchanges handshakes with all of them, and say that the limit of connections is also 50.
[15:30:28] <pevangelista> Now, what I want to know is, what does the client do when a peer asks for a connection with it, in the event that a peer not connected to the client receives the client's address from the tracker?
[15:30:39] <pevangelista> Can someone help me, please?
[15:30:56] <The_8472> you can either accept or drop the connection
[15:31:12] <The_8472> but generally the tracker only returns a subset of the peers in a swarm
[15:31:19] <The_8472> thus its lists are not binding
[15:31:38] <The_8472> the tracker is just one possible souce among many
[15:33:03] <pevangelista> That makes sense, but I was thinking (probably wrongly) that dropping these kinds of connections might affect performance somehow
[15:34:13] <The_8472> well, it might be good to keep some room for incoming connections within your max-connections threshold
[15:34:28] <The_8472> to allow NATed peers to connect to you
[15:34:37] <Andrius> if you already have enough connections, _not_ dropping new connections will have negative impact on performance
[15:34:56] <The_8472> unless you drop old connections of course
[15:35:21] <The_8472> in a carefully limited manner of course....
[15:35:45] <The_8472> anyway, such behavior is up to implementations, they're not specified
[15:47:20] <pevangelista> That helped a lot! Thank you very much
[16:11:33] *** cyb2063 has quit IRC
[16:15:59] *** pevangelista has quit IRC
[16:29:10] *** DaveMastine has joined #bittorrent
[16:30:39] <DaveMastine> guys everytime i try to run deluge it keeps giving me this message "deluge.exe  has ecnountered a problem and need to close. We are sorry for the inconvenience."
[16:31:07] <DaveMastine> can anyone advice please
[16:32:09] <DeHackEd> it crashes?
[16:32:13] <DeHackEd> got upgrades?
[16:32:31] <charles> DaveMastine: possibly ask in #deluge?
[16:40:01] <DaveMastine> DeHackEd, yes crashes
[17:00:44] *** DaveMastine has quit IRC
[17:41:00] *** bpot has quit IRC
[17:51:48] *** bpot has joined #bittorrent
[17:56:08] *** waldorf_ has quit IRC
[17:58:14] *** waldorf_ has joined #bittorrent
[18:06:34] *** gilles has joined #bittorrent
[18:24:05] *** goussx has quit IRC
[18:25:56] *** Elrohir has joined #bittorrent
[18:52:06] *** kuber has joined #bittorrent
[18:52:37] *** goussx has joined #bittorrent
[18:52:54] <kuber> does anyone know of a client that can be configured to be extremely verbose? I'd like to be able to scrape logs and get all connections for torrents im seeding, time periods, maybe even data transferred.
[18:53:19] <kuber> id like to write something to generate maps of debian iso torrents im seeding
[18:53:19] <Nolar> azureus/vuze
[18:53:31] <kuber> hm. are either of those cli?
[18:53:37] *** KyleK_ has joined #bittorrent
[18:53:51] <Nolar> sort of ;)
[18:53:58] <kuber> heh. this is on a headless debian box
[18:54:08] <Nolar> ya, it takes a bit of work
[18:54:27] <Nolar> i'm sure others can all be set to verbose output
[18:55:34] <kuber> I really like rtorrent but haven't been able to find a way to do it -- the closest I got was a config variable which seems to now be deprecated :(
[18:55:36] *** Elrohir has quit IRC
[18:57:23] *** The_8472 has quit IRC
[18:57:44] *** wadim has joined #bittorrent
[18:57:46] *** wadim is now known as The_8472
[18:59:11] *** _rafi1_ has joined #bittorrent
[19:00:53] *** azimuth1 has joined #bittorrent
[19:01:56] <azimuth1> hi everyone! I need information about BT protocol, namely how the blocks are selected to request within a piece
[19:03:29] <DreadWingKnight> 16384 bytes, hard set to multiples from the piece boundary
[19:03:31] <DreadWingKnight> currently
[19:04:17] <azimuth1> but are the blocks downloaded in order? I mean starting from block nr 0 and so on
[19:04:21] <azimuth1> or?
[19:04:58] <DreadWingKnight> not necessarily
[19:05:18] <The_8472> that's mostly up to the clients
[19:05:29] <DreadWingKnight> and pieces (next division up, where hash checks actually happen) are ideally downloaded in a rarest-first then random order
[19:05:51] <The_8472> the spec even allows (or used to) more than 16KiB, but most clients will disconnect if you request larger chunks
[19:06:16] <azimuth1> DreadWingKnight so you mean basically there is rarest first for both pieces and blocks?
[19:06:30] <azimuth1> rarest first algorithm I mean
[19:06:38] <DreadWingKnight> blocks you can't tell rarity
[19:06:47] <DreadWingKnight> because you either have all the blocks of a piece or you don't
[19:07:00] <azimuth1> hmm ok
[19:08:03] <DreadWingKnight> you don't share partially downloaded pieces
[19:08:39] <azimuth1> I am implementing a simple BT client for my project and currently it basically selects blocks in a piece randomly. Is that a common way of selecting blocks to download?
[19:09:07] <The_8472> selecting them in order would be better
[19:09:13] <The_8472> and you can pipeline requests
[19:09:16] <DreadWingKnight> blocks within a piece, download in order
[19:09:29] <DreadWingKnight> pieces within a torrent, try for rarest first, then random
[19:09:41] <azimuth1> aha thank you
[19:09:54] <azimuth1> then I will need to change the behavior of my program
[19:10:05] <azimuth1> thank you
[19:10:24] <azimuth1> by the way, is that documented somewhere?
[19:10:38] <azimuth1> I mean the block selection
[19:11:15] <azimuth1> I have found information about rarest piece first and piece selection but not the block selection
[19:11:28] <The_8472> |19:17:10| <The_8472> selecting them in order would be better
[19:11:29] <The_8472> |19:17:16| <The_8472> and you can pipeline requests
[19:11:46] <The_8472> that's all documentation you can get, really
[19:11:55] <azimuth1> :)
[19:11:55] <The_8472> beyond that, you'd have to read the source of various clients
[19:11:56] <azimuth1> ok
[19:12:03] <DreadWingKnight> block selection within a piece is entirely up to individual clients, isn't it?
[19:12:09] <The_8472> yes
[19:12:12] <DreadWingKnight> as long as the request size is compatible
[19:12:18] <The_8472> yes
[19:12:22] <azimuth1> I see
[19:12:40] <azimuth1> thanks again
[19:12:42] <azimuth1> bye
[19:12:57] <The_8472> many things aren't specified in bittorrent. there's lots of wiggle room for the implementations
[19:13:07] *** azimuth1 has left #bittorrent
[19:20:06] <mpl> which imho is pretty confusing for rookies like me. granted, it leaves some floor for improvements, but it also makes it harder for ppl not used to those kind of programming.
[19:20:19] <Nolar> <The_8472> selecting them in order would be better  <<< in order is also far superior for disk io reasons
[19:20:20] <mpl> s/those/that/
[19:46:59] <K`Tetch> quick Q, is the hash of the torrent file included in inter-peer data transfers?
[19:47:52] <K`Tetch> you know, 10 blocks sent from seed a to leecher b, would the hash, the piece number and the block identifiers all be sent?
[19:54:10] <K`Tetch> no matter, found it
[19:58:54] <Nolar> would not
[19:59:10] <Nolar> just byte ranges
[19:59:28] <Nolar> up to the receive to construct it together properly with the metadata in the .torrent
[20:29:56] *** spoop has joined #bittorrent
[20:40:57] <The_8472> K`Tetch, i think there is some extension in tribler that does this. but normally not, no
[20:41:23] <The_8472> but you can get the .torrent (and thus all piece hashes) from other peers
[20:43:57] <K`Tetch> wasn't what i was asking
[20:44:39] <K`Tetch> was asking if the peer communication gave the hash too, was something i was speculating about re: network neutrality. reading the specs i found it does
[20:50:40] <The_8472> *scratching head*
[20:50:46] <The_8472> which hash?
[20:52:52] *** bittwist has joined #bittorrent
[20:53:03] *** Nolar has quit IRC
[20:53:06] <K`Tetch> the sha1
[20:53:12] *** Nolar has joined #bittorrent
[20:57:38] *** bt42 has quit IRC
[20:57:48] <The_8472> K`Tetch, err... it's all sha1
[20:58:01] <K`Tetch> yeah, I found what i needed anyway
[20:58:01] <The_8472> did you mean the infohash or the piece hash?
[20:58:06] <K`Tetch> infohash
[20:58:52] <The_8472> well, that is exachanged with the handshake (although it's not visible to anyone except the 2 peers if the connection is encrypted)
[20:58:59] <The_8472> doesn't have anything to do with piece messages
[20:59:43] <K`Tetch> I was wondering about dpi, if the data in a torrent transfer could be identified to a particular torrent hash, so the identity of the torrent data could be identified
[20:59:57] <K`Tetch> and thus who owns the copyrgith and its sharable state
[21:00:22] <The_8472> well, they'd have to obtain the .torrents or at least torrent-filecontent mappings too in some way
[21:00:40] <The_8472> but technically it's possible with un-encrypted connections, yes
[21:03:06] <The_8472> though we could easily thwart that kind of attack with a minor modification
[21:03:55] <The_8472> well, no
[21:04:00] <The_8472> but we could make it more expensive
[21:04:23] <The_8472> or just use encryption, that keeps them from snooping the data without performing MITM
[21:05:59] <Nolar> <K`Tetch> I was wondering about dpi, if the data in a torrent transfer could be identified to a particular torrent hash, so the identity of the torrent data could be identified  <<< yup
[21:06:16] <Nolar> that's why one uses https to download the .torrent :)
[21:07:25] <Nolar> nobody's really bothered to do that afaik, since there's no good database of hashes to compare too
[21:33:00] *** fjfalcon has joined #bittorrent
[21:35:35] *** The_8472 has quit IRC
[21:35:56] *** wadim has joined #bittorrent
[21:35:58] *** wadim is now known as The_8472
[21:38:37] *** _rafi1_ is now known as _rafi_
[22:02:14] *** uau` has joined #bittorrent
[22:04:38] *** Elrohir has joined #bittorrent
[22:15:23] *** uau has quit IRC
[22:15:51] *** fjfalcon has quit IRC
[22:17:33] *** uau` is now known as uau
[22:27:59] *** Nolar is now known as Nolar___________
[22:33:05] *** Nolar___________ is now known as Nolar
[22:49:10] *** _rafi_ has quit IRC
[22:53:44] *** The_8472 has quit IRC
[22:54:04] *** wadim has joined #bittorrent
[22:54:06] *** wadim is now known as The_8472
[23:14:09] *** waldorf_ has quit IRC
[23:14:17] *** waldorf_ has joined #bittorrent
[23:18:00] *** waldorf_ has left #bittorrent
[23:18:15] *** waldorf_ has joined #bittorrent
[23:20:33] *** stalled_ has joined #bittorrent
[23:21:30] *** stalled has quit IRC
[23:21:40] *** stalled_ is now known as stalled
[23:28:23] *** PN has joined #bittorrent
[23:34:10] *** Elrohir has quit IRC
[23:38:45] *** KyleK_ has quit IRC
[23:42:26] *** ProperNoun has quit IRC
[23:46:29] *** Andrius has quit IRC
[23:49:46] *** Waldorf- has joined #bittorrent





top