Re: PEX and listening ports

On 16 Dec 2011, at 11:57, Michael Sommerville wrote:
> On Fri, Dec 16, 2011 at 5:41 AM,  <arvid <at> cs.umu.se> wrote:
>> Quoting Michael Sommerville <msommerville <at> gmail.com>:
>>> Hi,
>>> 
>>> I'm attempting to use libtorrent with ut_pex & ut_metadata extensions
>>> and no other trackers or dht. This does work except that the peers
>>> don't learn each others listening ports correctly and thus just get
>>> download everything from the initial 'canonical' seed.
>>> 
>>> From my investigation so far, it seems that pex messages sent to
>>> clients contain the other peers' outbound port rather than their
>>> listening port, even though this information is exchanged correctly in
>>> the extension handshake. Presumably the intent of pex is to share the
>>> listening port?
>> 
>> Yeah, either that or not sharing incoming peers at all (esp. not the ones that
>> don't advertise a listen port). The code currently (is supposed to) just filter
>> incoming peers. (see ut_pex.cpp/send_peer() this is the predicate determining
>> whether or not a peer belongs in the pex set).
>> 
>> To do this, I believe the peer_connection needs to be extended to not just have
>> an incoming/outgoing connection flag (m_active), but also have an
>> incoming_with_port sate (set where the "p" listen port header is parsed out in
>> bt_peer_connection.cpp). This could then be used in the predicate in ut_pex to
>> include these peers. Maybe it would be simpler to just store the listen port as
>> well, in peer_connection, and if it's != 0 it's assumed to be a valid listen
>> connection.
>> 
>> I'd be happy to help you out with any questions if you want to give this patch a

[PATCH] Export session_settings defaults

This tiny patch adds TORRENT_EXPORT declarations for min_memory_usage() & high_performance_seed()
functions. 

-Mike

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

_______________________________________________
Libtorrent-discuss mailing list
Libtorrent-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss

Re: [PATCH] Export session_settings defaults

Quoting Michael Sommerville <msommerville <at> gmail.com>:

> This tiny patch adds TORRENT_EXPORT declarations for min_memory_usage() &
> high_performance_seed() functions. 

Thanks, applied.

--

-- 
Arvid Norberg

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Re: PEX and listening ports

Quoting Michael Sommerville <msommerville <at> gmail.com>:

> On 16 Dec 2011, at 11:57, Michael Sommerville wrote:
> > On Fri, Dec 16, 2011 at 5:41 AM,  <arvid <at> cs.umu.se> wrote:
> >> Quoting Michael Sommerville <msommerville <at> gmail.com>:
> >>> Hi,
> >>> 
> >>> I'm attempting to use libtorrent with ut_pex & ut_metadata extensions
> >>> and no other trackers or dht. This does work except that the peers
> >>> don't learn each others listening ports correctly and thus just get
> >>> download everything from the initial 'canonical' seed.
> >>> 
> >>> From my investigation so far, it seems that pex messages sent to
> >>> clients contain the other peers' outbound port rather than their
> >>> listening port, even though this information is exchanged correctly in
> >>> the extension handshake. Presumably the intent of pex is to share the
> >>> listening port?
> >> 
> >> Yeah, either that or not sharing incoming peers at all (esp. not the ones
> that
> >> don't advertise a listen port). The code currently (is supposed to) just
> filter
> >> incoming peers. (see ut_pex.cpp/send_peer() this is the predicate
> determining
> >> whether or not a peer belongs in the pex set).
> >> 
> >> To do this, I believe the peer_connection needs to be extended to not just
> have
> >> an incoming/outgoing connection flag (m_active), but also have an
> >> incoming_with_port sate (set where the "p" listen port header is parsed

Magnet URIs: support for xt=urn:md5 and xt=urn:sha1

Hi, I've been directed here by the people at freenode/#deluge.

So of course xt=urn:btih is supported for magnet URIs, but the BTIH is
not always available before downloading the file. Quite often the MD5,
SHA1 and/or SHA256 is available on web servers. But I want to use
Bittorrent.

I suggest that DHT is used to associate the various hashes with the BTIH.

The depth of my knowledge on DHT is little more than this:
http://en.wikipedia.org/wiki/Distributed_hash_table#Structure

So as far as I understand, seeders should 'put( SHA1 of MD5, BTIH )'
and 'put( SHA1 of SHA1, BTIH )'. Then a leacher with only the SHA1 of
the file would 'get( SHA1 of SHA1 )', and with the returned BTIH would
start downloading as usual.

I'm much more interested in SHA1 support than MD5, due to collision
vulnerabilities of MD5, but it would still be nice to have both.

Thank you.
James Haigh.

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Talk about libtorrent-rasterbar in spanish

Hi,
I gave a talk about libtorrent rasterbar in the last BSDday Argentina (2011).
There is a video and it can be found in
http://www.youtube.com/watch?feature=player_detailpage&v=Bz8ykWbVbJc
Damian
http://dfbsd.trackbsd.org.ar

------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2

resume data and torrent info file_storage

Hi arvid, mm i having some problems when loading resume data with
mapped_files, (renamed files), if later i ask for
libtorrent::torrent_info::files() or orig_files() they both return the same
original name. But they effectively load the renamed file, making difficult
to so some cheking. I can force files() to return the mapped files names if
i rename files (via torrent_info) before adding the torrent.

Another thing i wanted to ask is if its possible after that is solved to
overwrite what the resume_data says about mapped_files before dding the
torrent, that way we can manipulate some error cheking if resume data was
not up to date (file existence, wich file, etc).

Thanks.

Pablo.

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

Please ensure the reply to this mail is tekert <at> tekert.com.ar

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

About limiting offered pieces

Hi there,


I was about to start a project where we have to implement a modified bittorrent protocol. The main
differences with the standard protocol are:

- once a peer serves a piece, it never sends (or tries to obtain) it again.
- there is always a bandwidth limit between any two peers.

There is also an implementation constraint: it must be done from Python. So I've been looking at the sources
and it seems the second constraint can be implemented with
set_peer_upload_limit()/set_peer_download_limit(), but I don't know if there is a way for limiting
the pieces offered/accepted to/from other peers. Could this be done from Python?


Thanks in advance




Alvaro