From 46d8706b0edbe1d3103d1a9070282857b121a619 Mon Sep 17 00:00:00 2001 From: Sam T Date: Sun, 7 Jul 2013 03:42:14 +0400 Subject: + Literate thread throttling. --- src/Network/BitTorrent/Internal.lhs | 70 +++++++++++++++++++++---------------- 1 file changed, 39 insertions(+), 31 deletions(-) (limited to 'src/Network/BitTorrent/Internal.lhs') diff --git a/src/Network/BitTorrent/Internal.lhs b/src/Network/BitTorrent/Internal.lhs index 3f8f0371..078920a4 100644 --- a/src/Network/BitTorrent/Internal.lhs +++ b/src/Network/BitTorrent/Internal.lhs @@ -170,7 +170,7 @@ Thread layout -------------- +------------------------------------------------------------------------ When client session created 2 new threads appear: @@ -193,20 +193,19 @@ When client\/swarm\/peer session gets closed kill the corresponding threads, but flush data to disc. (for e.g. storage block map) So for e.g., in order to obtain our first block we need to run at -least 7 threads: main thread, 2 client session thread, 3 swarm session +least 7 threads: main thread, 2 client session threads, 3 swarm session threads and PeerSession thread. -> {----------------------------------------------------------------------- -> Client session -> -----------------------------------------------------------------------} +Thread throttling +------------------------------------------------------------------------ -> {- NOTE: If we will not restrict number of threads we could end up -> with thousands of connected swarm and make no particular progress. -> -> Note also we do not bound number of swarms! This is not optimal -> strategy because each swarm might have say 1 thread and we could end -> up bounded by the meaningless limit. Bounding global number of p2p -> sessions should work better, and simpler.-} +If we will not restrict number of threads we could end up +with thousands of connected swarm and make no particular progress. + +Note also we do not bound number of swarms! This is not optimal +strategy because each swarm might have say 1 thread and we could end +up bounded by the meaningless limit. Bounding global number of p2p +sessions should work better, and simpler. > -- | Each client might have a limited number of threads. > type ThreadCount = Int @@ -215,16 +214,28 @@ threads and PeerSession thread. > defaultThreadCount :: ThreadCount > defaultThreadCount = 1000 -> {- PERFORMANCE NOTE: keeping torrent metafiles in memory is a _bad_ -> idea: for 1TB of data we need at least 100MB of metadata. (using 256KB -> piece size). This solution do not scale further. Solution with -> TorrentLoc is much better and takes much more less space, moreover it -> depends on count of torrents but not on count of data itself. To scale -> further, in future we might add something like database (for -> e.g. sqlite) for this kind of things.-} - -> -- | Identifies location of +Torrent Map +------------------------------------------------------------------------ + +TorrentMap is used to keep track all known torrents for the +client. When some peer trying to connect to us it's necessary to +dispatch appropriate 'SwarmSession' (or start new one if there are +none) in the listener loop: we only know 'InfoHash' from 'Handshake' +but nothing more. So to accept new 'PeerSession' we need to lookup +torrent metainfo and content files (if there are some) by the +'InfoHash' and only after that enter exchange loop. + +*PERFORMANCE NOTE:* keeping torrent metafiles in memory is a _bad_ +idea: for 1TB of data we need at least 100MB of metadata. (using 256KB +piece size). This solution do not scale further. Solution with +TorrentLoc is much better and takes much more less space, moreover it +depends on count of torrents but not on count of data itself. To scale +further, in future we might add something like database (for +e.g. sqlite) for this kind of things. + +> -- | Local identification info location about > data TorrentLoc = TorrentLoc { +> -- | > metafilePath :: FilePath > , dataPath :: FilePath > } @@ -232,19 +243,16 @@ threads and PeerSession thread. > validateTorrent :: TorrentLoc -> IO () > validateTorrent = error "validateTorrent: not implemented" -> -- | TorrentMap is used to keep track all known torrents for the -> -- client. When some peer trying to connect to us it's necessary to -> -- dispatch appropriate 'SwarmSession' (or start new one if there are -> -- none) in the listener loop: we only know 'InfoHash' from -> -- 'Handshake' but nothing more. So to accept new 'PeerSession' we -> -- need to lookup torrent metainfo and content files (if there are -> -- some) by the 'InfoHash' and only after that enter exchange loop. + > -- > type TorrentMap = HashMap InfoHash TorrentLoc -> {- NOTE: basically, client session should contain options which user -> app store in configuration files. (related to the protocol) Moreover -> it should contain the all client identification info. (e.g. DHT) -} +Client session +------------------------------------------------------------------------ + +Basically, client session should contain options which user app store +in configuration files. (related to the protocol) Moreover it should +contain the all client identification info. (e.g. DHT) > -- | Client session is the basic unit of bittorrent network, it has: > -- -- cgit v1.2.3