<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent">
    <title>gmane.network.bit-torrent.libtorrent</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4489"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4488"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4487"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4486"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4485"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4484"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4483"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4482"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4481"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4480"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4479"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4478"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4477"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4476"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4475"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4474"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4473"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4472"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4471"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4470"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4489">
    <title>(no subject)</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4489</link>
    <description>&lt;pre&gt;How can I know if all the torrents finished checking when startup?
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>ximply</dc:creator>
    <dc:date>2013-06-16T05:03:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4488">
    <title>About torrent checking</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4488</link>
    <description>&lt;pre&gt;How can I know if all the torrents finished checking when startup?



发自 Windows 邮件
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Libtorrent-discuss mailing list
Libtorrent-discuss&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
&lt;/pre&gt;</description>
    <dc:creator>ximply</dc:creator>
    <dc:date>2013-06-16T05:07:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4487">
    <title>Re: fastresume problem</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4487</link>
    <description>&lt;pre&gt;
On Jun 14, 2013, at 3:38 PM, arvid wrote:


However, this would have the disadvantage of pausing the other torrents
if supporting continuous availability with peers is desired.


This is good to know.  In my case it's probably not important (see below)
and better left as is, but in the OP's case may be less complex and better.


this very well may be, this original function was developed against an
earlier version of lib torrent (version 14.x I think), and I recall that there
was a need to wait for the torrent to be valid before a save operation
would not cause it to crash; I was testing the reaction of adding a
torrent to the session and then immediately shutting down the client and
has_metadata was the most succinct test for readiness.  Here's some
unnecessary code the attempted to do the same thing

     switch(t_status.state)
      {  case torrent_status::queued_for_checking:
         case torrent_status::checking_files:
         case torrent_status::checking_resume_data:
            return false;


I h&lt;/pre&gt;</description>
    <dc:creator>Jeff Waller</dc:creator>
    <dc:date>2013-06-14T23:59:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4486">
    <title>Re: fastresume problem</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4486</link>
    <description>&lt;pre&gt;
Another way to do this is to pause the session. That way you can save 
the paused and auto-managed state of the torrents in the fast resume as 
well.

You don't actually have to wait for the paused alert. Even though pause 
is asynchronous, the save resume operation will not skip ahead. Both 
operations are ordered in a queue in the libtorrent thread.


You may scale a bit better by skipping this step. It's not fatal to ask 
to save resume data for a torrent that doesn't have metadata. Asking for 
the status here will cause one full round-trip to the libtorrent thread 
for each torrent, which can be quite slow if you have a lot of torrents.


There's a class that takes care of loading and saving resume data and 
torrent state which may serve as inspiration:

   
https://github.com/arvidn/libtorrent-webui/blob/master/src/save_resume.cpp

&lt;/pre&gt;</description>
    <dc:creator>arvid</dc:creator>
    <dc:date>2013-06-14T19:38:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4485">
    <title>Re: fastresume problem</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4485</link>
    <description>&lt;pre&gt;You know I've noticed this behavior only when the process has been killed and
not allowed to stop gracefully.  Otherwise, I've never seen it happen.  There are a
few differences in our setups though.  C++ vs. python, and different versions of
libtorrent.  



That said, I'll describe what I do and you can compare?


Make sure the torrent is paused before writing out fast resume data.  To do this

torrent_handle.auto_managed(false);
torrent_handle.pause();

then wait for torrent_paused_alert

now once the torrent is paused and is valid, you can generate the resume data.
it appears to me this is a correct test for is_saveable()

bool is_saveable(const torrent_handle &amp;amp;t_handle)
{ 
   if(!t_handle.is_valid()) return false;
   if(t_handle.status().has_metadata) return true;
   return false;
}

…elsewhere...

if(is_saveable(t)) t.save_resume_data();

then wait for save_resume_data_alert 

You can stop the client as soon as you receive save alerts for all of
the torrents that were paused and saved in this way.

O&lt;/pre&gt;</description>
    <dc:creator>Jeff Waller</dc:creator>
    <dc:date>2013-06-14T18:52:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4484">
    <title>Re: Problem with libtorrent and browser speed</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4484</link>
    <description>&lt;pre&gt;
libtorrent is supposed to limit the number of half-open connections
to match the version of XP you're running.

My guess would be that your router is having a hard time dealing
with the DHT traffic (because it causes a lot of NAT pin-holes to
be opened). You could try disabling the DHT.

You could also try lowering the number of peers per torrent and
globally.

&lt;/pre&gt;</description>
    <dc:creator>arvid</dc:creator>
    <dc:date>2013-06-14T14:11:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4483">
    <title>Re: Problem with libtorrent and browser speed</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4483</link>
    <description>&lt;pre&gt;2013/5/29 Alexander Koshelev &amp;lt;alexander.koshelev&amp;lt; at &amp;gt;crystalnix.com&amp;gt;:

AFAIR Windows XP has a limit for half-opened TCP connections, and I
believe downloading a popular torrent with enough peers in swarm
satisfies the limit.

There was a patch or something for this, adjusting the limit from 10
connections to a bigger value. Unfortunately I cannot give more
details.

--
  Georg Rudoy
  LeechCraft — http://leechcraft.org

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Libtorrent-discuss mailing list
Libtorrent-discuss&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
&lt;/pre&gt;</description>
    <dc:creator>Georg Rudoy</dc:creator>
    <dc:date>2013-06-14T07:18:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4482">
    <title>libtorrent fails to configure on Fedora 18 x86_64without explicit assignment of libdir</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4482</link>
    <description>&lt;pre&gt;
This is because the ax_boost macros incorrectly assume that BOOSTLIBDIR = /usr/lib
when the boost include files are located in /usr/include.  On Fedora 18 64 bit, this is
incorrect, because all of the boost libraries are located in /usr/lib64 not /usr/lib.  So while
the check for boost succeeds, the check for the boost system library fails because 
it never looks in /usr/lib64.

This can be overcome by configure --with-boost-libdir=/usr/lib64

The original author of the boost support autoconf macro does not maintain this anymore
apparently.  His website says he's looking for another maintainer (and that was in 2009).

There is another m4 boost support library available that may not be maintained either
(was last updated in 2011), but is more up to date and it does not fail the configuration
step.  I'm attaching it.  

If this has been considered before, well then at least there's a way to compile, though
it not immediately apparent.  Otherwise, I think integrating this second support lib
should be fairly st&lt;/pre&gt;</description>
    <dc:creator>Jeff Waller</dc:creator>
    <dc:date>2013-06-06T03:26:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4481">
    <title>Problem with libtorrent and browser speed</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4481</link>
    <description>&lt;pre&gt;Hi.

I use python 2.6 and libtorrent 0.16.8.
I have build-in browser in my app.
Everything works great on Windows 7, but on Windows XP I have one problem.
When I start downloading any torrent, browser in my app stop loading any
urls.
I tried set downloading/uploading speed limit to 10 KB/s, but it is not
help.
I really have not idea why it happens.


--
Alexander Koshelev
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Alexander Koshelev</dc:creator>
    <dc:date>2013-05-29T06:58:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4480">
    <title>remove files</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4480</link>
    <description>&lt;pre&gt;hi,about libtorrent, if there are 2 files in a torrent, and now I want to download one of the file, so what can I do to remove the other file? I can not find the function(API) in class torrent_handle or torrent_info....help! thanks!

2013-06-14



毛志杰
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Libtorrent-discuss mailing list
Libtorrent-discuss&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
&lt;/pre&gt;</description>
    <dc:creator>毛志杰</dc:creator>
    <dc:date>2013-06-14T03:30:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4479">
    <title>fastresume problem</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4479</link>
    <description>&lt;pre&gt;Hi.

I use python 2.6 and libtorrent 0.16.5.
My problem: after torrent finish, it can recheck on the next program start.

I tested it in Deluge 1.3.4 with python 2.6 and libtorrent 0.16.5 and I get
the same thing.
I run Deluge and download small torrent (about 3 MB). After torrent finish,
I click "File -&amp;gt; Quit". And run Deluge again. After this torrent rechecking
and I get this console message: "fast resume rejected: mismatching file
size". It works in about half of cases for me.

Also I made another test.
I added this code to the top of torrentmanager.py:

import win32con, win32file

DIR_EXCLUDES = set(['.', '..'])
MASK = win32con.FILE_ATTRIBUTE_DIRECTORY | win32con.FILE_ATTRIBUTE_SYSTEM
REQUIRED = win32con.FILE_ATTRIBUTE_DIRECTORY
FindFilesW = win32file.FindFilesW

def get_dir_size(path):
    total_size = 0
    try:
        items = FindFilesW(path + r'/*')
    except Exception, e:
        print e
        return total_size

    for item in items:
        total_size += item[5]
        if (item[0] &amp;amp; MASK == R&lt;/pre&gt;</description>
    <dc:creator>Alexander Koshelev</dc:creator>
    <dc:date>2013-05-15T07:05:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4478">
    <title>Re: peer_info "connected" state flag</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4478</link>
    <description>&lt;pre&gt;Hello Arvid,

Thanks for shedding the light on this.  I think I have enough to go on.  BTW, I forgot to thank you for replying to one of my previous question on "Observing without downloading" on 5/1.  Somehow I missed your replies until now.


On Jun 12, 2013, at 6:23 PM, arvid &amp;lt;arvid&amp;lt; at &amp;gt;cs.umu.se&amp;gt; wrote:


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Ricky Huang</dc:creator>
    <dc:date>2013-06-13T10:03:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4477">
    <title>Re: peer_info "connected" state flag</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4477</link>
    <description>&lt;pre&gt;I have tested with the "3 explicit states and implicit connected state" assumption with my code today and it seems like that is the case.


On Jun 11, 2013, at 11:48 PM, Jeff Waller &amp;lt;truthset&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Ricky Huang</dc:creator>
    <dc:date>2013-06-13T10:00:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4476">
    <title>Re: peer_info "connected" state flag</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4476</link>
    <description>&lt;pre&gt;
When the connecting flag is not set, the peer is connected.


How about waiting until you have the data you want before 
disconnecting?


What kind of status are you interested in?

You can most likely do the things you want to do in a plugin. I would
expect you to use a plugin to collect the information you're interested
in for instance.

If you don't want to upload, don't have any data. If you don't to 
download,
just set the priority of all pieces to 0. In order to avoid having 
libtorrent
disconnect immediately, you must also disable 
"close_redundant_connections"
(or something along those lines).

&lt;/pre&gt;</description>
    <dc:creator>arvid</dc:creator>
    <dc:date>2013-06-13T01:23:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4475">
    <title>Re: socks proxy obedience</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4475</link>
    <description>&lt;pre&gt;
It doesn't when anonymous mode is enabled.

In the current stable release, anonymous mode is disabled by default, 
but
it is enabled by default in the next major release (trunk).

(anonymous mode is not a good name, I'm considering renaming it to 
privacy mode in trunk)


hostnames are resolved by the proxy as long as  
proxy_settings::proxy_hostname is
set to true (which it is by default).


It depends on the anonymous mode setting. By default, UDP traffic fail 
open when the
proxy fails. This is because how popular it is to run socks5 proxies 
that don't support UDP.

When enabling anonymous mode however, UDP traffic fail closed.

The more subtle point is that some traffic may not be supported by 
certain kinds
of proxies (UDP over an HTTP proxy for instance). In those cases, the 
proxy is
not used, and the traffic is going out over the local interface. If 
anonymous mode is set,
everything fails closed.

In the next major release (currently trunk) there is a separate option 
to make anything
not going ov&lt;/pre&gt;</description>
    <dc:creator>arvid</dc:creator>
    <dc:date>2013-06-12T17:43:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4474">
    <title>Re: peer_info "connected" state flag</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4474</link>
    <description>&lt;pre&gt;What I have see through experimentation is that there can be 4 states:

Connecting
Handshaking
Queued
Connected

There's an explicit state flag for the first 3, so everything thing else is connected.  
Note I have set aside logic for queued but have not encountered it yet.

-Jeff

On Jun 11, 2013, at 7:58 PM, Ricky Huang wrote:



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Jeff Waller</dc:creator>
    <dc:date>2013-06-12T06:48:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4473">
    <title>peer_info "connected" state flag</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4473</link>
    <description>&lt;pre&gt;Hello all,

In the peer_info struct, there's an enum of flags for peer states.  There's a "handshake" and "connecting" state, however I do not see a "connected" state.

What my project / custom-libtorrent build tries to do is to collect peer data for trending analysis without actually exchanging any file data with the swarm.  I have observed that if I cut off the client too early in the game, I get incomplete data on client, num_pieces, progress, and etc.

So I am trying to find out at what point would I have the most complete client info /prior to/ actually exchanging data and so I can cut the client off.  I have also looked into the libtorrent plugin architecture, but I don't see any "on status update" or similar method I can hook into…


Thanks in advance!

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Ricky Huang</dc:creator>
    <dc:date>2013-06-11T23:58:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4472">
    <title>socks proxy obedience</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4472</link>
    <description>&lt;pre&gt;Hi,

I am adrelanos, maintainer of Whonix, which is an anonymous operating
system. [1]

Maybe you've heard, that BitTorrent over Tor is unwanted. [2] That might
have changed. [3] [4] [5]

I am going to ask the Tor maintainers before adding a torrent client to
Whonix, but before  to consider this, I have to find a suitable torrent
client. Since most are based on libtorrent, I have some questions.

Does libtorrent encode the IP and send it through the protocol? [2]

Does libtorrent resolve DNS through socks 4a/socks5 proxies or does it
fall back to system DNS?

Does libtorrent fail closed, i.e. does it just fail if the socks proxy
is offline or does it try without the proxy?

Cheers,
adrelanos

------------------------------------------------------------

Footnotes:

Due to Whonix design, it wouldn't really matter if there are any leaks
or not. As a precaution I don't want to ship any applications by
default, which use Tor's TransPort and per configuring them to prevent
identity correlation through circuit sha&lt;/pre&gt;</description>
    <dc:creator>adrelanos</dc:creator>
    <dc:date>2013-06-10T12:09:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4471">
    <title>Re: how to disconnect peer</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4471</link>
    <description>&lt;pre&gt;
On Jun 9, 2013, at 11:25 AM, arvid wrote:


When this happens, what happens next?  When does the next connection 
attempt happen?  I realize this has moved outside the original scope of
the question, but might as well talk about it thoroughly while we're tailing
about it.  From libtorrent's point of view, what's the difference between
a peer that (theoretically) accepts a connection 50% of the time, but when it
does transmits 100% of the time and a peer that accepts the connection
100% of the time but transmits 50% of the time?  Or for that matter a peer
that accepts the connection 100% of the time and transmits 100% of the 
time but at 50% the speed?  From the standpoint of a peer's "quality" to
exchange data, are all 3 about the same?  Should the tendency of libtorrent
be to seek out data from all 3 of these peers equally?  Maybe this does 
happen already, but not explicitly.



------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT depar&lt;/pre&gt;</description>
    <dc:creator>Jeff Waller</dc:creator>
    <dc:date>2013-06-09T18:22:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4470">
    <title>Re: how to disconnect peer</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4470</link>
    <description>&lt;pre&gt;
When a peer rejects a connection because it doesn't have any slots 
left, it
still accepts the connection at the transport layer, to find out what 
kind
of connection it is and which torrent it's for, then disconnects.

i.e. those still counts as successful connects.

&lt;/pre&gt;</description>
    <dc:creator>arvid</dc:creator>
    <dc:date>2013-06-09T15:25:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4469">
    <title>Re: how to disconnect peer</title>
    <link>http://permalink.gmane.org/gmane.network.bit-torrent.libtorrent/4469</link>
    <description>&lt;pre&gt;
On Jun 9, 2013, at 1:47 AM, arvid wrote:


It could be online but ignores the request with some probability (slots full).
Note I may be associating refusal to transmit with making a successful
connection.


I think both schemes are similar in that that both reward success
with more attempts before stopping and tend to reduce to 1 try
for unresponsive peers. Both schemes are simplistic so yea if
one is not much better than then other why do all the work?
Completeness maybe.  Perhaps one is slightly more efficient. I've 
seen reconnection happen a reasonable amount of time,
at least for some torrents, however, which makes we wonder
about the population of semi-responsive peers.




------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.ne&lt;/pre&gt;</description>
    <dc:creator>Jeff Waller</dc:creator>
    <dc:date>2013-06-09T06:25:56</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.network.bit-torrent.libtorrent">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.network.bit-torrent.libtorrent</link>
  </textinput>
</rdf:RDF>
