Can't build python bindings on Solaris Express 11 (libtorrent 0.15.7)

Solaris Express 11, gcc-3.4.3 & gcc-4.4.6, boost_1_47_0, python2.6.

building 'libtorrent' extension
/usr/lib/python2.6/pycc -DNDEBUG -KPIC -I../../include -I/usr/local/include
-I/usr/include/python2.6 -c src/ip_filter.cpp -o
build/temp.solaris-2.11-i86pc-2.6/src/ip_filter.o -DTORRENT_USE_OPENSSL
-DWITH_SHIPPED_GEOIP_H -DBOOST_ASIO_HASH_MAP_BUCKETS=1021
-DBOOST_EXCEPTION_DISABLE -DBOOST_FILESYSTEM_VERSION=2
-DTORRENT_LINKING_SHARED
cc: unrecognized option `-KPIC'
In file included from
/usr/local/include/boost/python/object/make_instance.hpp:9,
                 from
/usr/local/include/boost/python/object/make_ptr_instance.hpp:8,
                 from
/usr/local/include/boost/python/to_python_indirect.hpp:11,
                 from
/usr/local/include/boost/python/converter/arg_to_python.hpp:10,
                 from /usr/local/include/boost/python/call.hpp:15,
                 from /usr/local/include/boost/python/object_core.hpp:14,
                 from /usr/local/include/boost/python/args.hpp:25,
                 from /usr/local/include/boost/python.hpp:11,
                 from src/ip_filter.cpp:6:
/usr/local/include/boost/python/object/instance.hpp:44: error: a casts to a
type other than an integral or enumeration type cannot appear in a
constant-expression
/usr/local/include/boost/python/object/instance.hpp:44: error: '->' cannot
appear in a constant-expression
/usr/local/include/boost/python/object/instance.hpp:44: error: `&' cannot
appear in a constant-expression

Modifying a torrent file

I need to modify torrent files without recreating the info array.  It
seems like this should be simple with torrent_info and create_torrent
exposed to python.  The torrent_info class has some helpful functions
that handle logic, e.g. add_tracker().  I tried the following:

old_info = lt.torrent_info(filename)
old_torrent = lt.create_torrent(old_info)
info_dict = old_torrent.generate()

... make changes to info_dict

new_info = lt.torrent_info(info_dict)

... make changes to new_info

new_torrent = lt.create_torrent(new_info)
data = lt.bencode(new_torrent.generate())

It's inefficient, but it seems to mostly work. However, the private
option doesn't ever get set to true in the new torrent_info.  There's
a spot in torrent_info::parse_info_section that looks like it should
set m_private.

Is there a better way to alter torrent files?  I guess I could
bdecode, alter, then bencode, but that would require reimplementing
logic already in torrent_info.

Thanks,

-John

Recording incoming connections

I'd like to see an alert for inbound connections, but the
peer_connect_alert only happens for outbound.  Would it be appropriate
to reuse this alert, or better to add another?  It would be helpful to
see both successful and unsuccessful incoming connections, even if the
peer is rejected for some reason.  Or maybe there's a more appropriate
way to record all connection attempts?

Thanks,

-jrr

------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/

Re: Recording incoming connections

Quoting John Reuning <john <at> ibiblio.org>:

> I'd like to see an alert for inbound connections, but the
> peer_connect_alert only happens for outbound.  Would it be appropriate
> to reuse this alert, or better to add another?  It would be helpful to
> see both successful and unsuccessful incoming connections, even if the
> peer is rejected for some reason.  Or maybe there's a more appropriate
> way to record all connection attempts?

peer_connect_alert includes a torrent handle. incoming connections don't have
torrent handles (at the time of accepting the connection at least). That
probably would make it more convenient to have a separate alert type for
incoming connections.

What does it mean for an incoming connection to fail btw? That no handshake is
received? that the info-hash is unknown?

If you're interested in providing a patch, I would be happy to check it in.

see session_impl::incoming_connection()

--

-- 
Arvid Norberg

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2

Re: Recording incoming connections

Thanks for the info.  I found the peer_blocked_alert cases, which seem
to cover the failure scenarios.  That leaves making an
incoming_connection_alert.  Creating the alert was simple, but I'm
having trouble determining the protocol and stream type from the
socket_type in session_impl::incoming_connection().

tcp::endpoint endp = s->remote_endpoint(ec);

I'm watching the traffic with tcpdump.  All I see is udp packets when
testing utp, but libtorrent still registers a connection as a
tcp::endpoint.  Am I missing something obvious?  Is there an easy way
to get the value of socket_type::m_type?

-jrr

On Fri, Sep 16, 2011 at 5:20 AM,  <arvid <at> cs.umu.se> wrote:
> Quoting John Reuning <john <at> ibiblio.org>:
>
>> I'd like to see an alert for inbound connections, but the
>> peer_connect_alert only happens for outbound.  Would it be appropriate
>> to reuse this alert, or better to add another?  It would be helpful to
>> see both successful and unsuccessful incoming connections, even if the
>> peer is rejected for some reason.  Or maybe there's a more appropriate
>> way to record all connection attempts?
>
> peer_connect_alert includes a torrent handle. incoming connections don't have
> torrent handles (at the time of accepting the connection at least). That
> probably would make it more convenient to have a separate alert type for
> incoming connections.
>

Re: Recording incoming connections

Quoting John Reuning <john <at> ibiblio.org>:

> Thanks for the info.  I found the peer_blocked_alert cases, which seem
> to cover the failure scenarios.  That leaves making an
> incoming_connection_alert.  Creating the alert was simple, but I'm
> having trouble determining the protocol and stream type from the
> socket_type in session_impl::incoming_connection().
> 
> tcp::endpoint endp = s->remote_endpoint(ec);
> 
> I'm watching the traffic with tcpdump.  All I see is udp packets when
> testing utp, but libtorrent still registers a connection as a
> tcp::endpoint.  Am I missing something obvious?  Is there an easy way
> to get the value of socket_type::m_type?

The UDP traffic is probably a mixture of DHT and uTP traffic. I take it you're
not interested in the DHT here. As for uTP, libtorrent has a stream socket
interface for the uTP sockets, which means internally it sort of looks like a
TCP socket. The point, though, is that both TCP sockets and uTP sockets need to
have the same interface for the rest of the library to be transport protocol
agnostic. i.e. remote_endpoint() need to return the same type in both cases, I
chose to go with the tcp::endpoint.

If you're interested in figuring out more details about which transport is
actually used for the socket, you can look at socket_type (socket_type.hpp)
which essentially is a variant type with a few different possible types. There's
no way to ask directly which type it is, but you can use the get<>() member
function to ask for specific types.

for instance, to know if it's a uTP socket, you would say:

Re: Recording incoming connections

I see what you mean about checking type via get(). I added a type() method to socket_type. One interesting
discovery was getting an i2p stream when testing utp. It's possible I turned off a libtorrent session
feature required for utp (e.g. dht), but I can't get transmission utp to work with libtorrent.  The mystery
was libtorrent seeing the client as i2p.

One more question: where is the logic that creates the appropriate stream_type objects?  The object seems
to come from asio during a callback.

Thanks,

-jrr

On Sep 16, 2011, at 3:33 PM, arvid <at> cs.umu.se wrote:

> 
> if (m_socket->get<stream_socket>()) {
>   // ...
> }
> 
> keep in mind that socks5, http proxying and SSL are all implemented as stream
> socket layers, so there are more streams and combinations, like:
> ssl_stream<stream_socket>, socks5_stream, i2p_stream and
> ssl_stream<socks5_stream> etc. They're all enumerated in socket_type.hpp.
> 
> -- 
> Arvid Norberg
------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2

Re: Recording incoming connections

Quoting John Reuning <john <at> ibiblio.org>:

> I see what you mean about checking type via get(). I added a type() method to
> socket_type. One interesting discovery was getting an i2p stream when testing
> utp. It's possible I turned off a libtorrent session feature required for utp
> (e.g. dht), but I can't get transmission utp to work with libtorrent.  The
> mystery was libtorrent seeing the client as i2p.

hm. i2p can be enabled and disabled separately at build time as well. Either
way, regardless of which features are enabled, the enums representing the type
in socket_type doesn't change. So even an incompatibility in these configuration
defines between build time and link time should not result in a utp socket
looking like an i2p socket. Those enums are defined as template meta functions
in socket_type.hpp.

I don't know what could be causing that (unless you're actually running and
configuring i2p on your machine).

> One more question: where is the logic that creates the appropriate
> stream_type objects?  The object seems to come from asio during a callback.

There's a function called instantiate_connection() (in
instantiate_connection.cpp) which creates the concrete socket type and returns a
socket_type. You might want to look in there to see why it would create an i2p
socket.

--

-- 
Arvid Norberg

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

Re: Recording incoming connections

Quoting John Reuning <john <at> ibiblio.org>:

> I found instantiate_connection.cpp and the logic, thanks.  After
> digging around, the i2p connection report turned out to be user error.
>  I've attached a patch that adds an incoming_connection_alert.  It has
> the type() addition to the socket_type interface.  If you think using
> the get() method you outlined is preferable, I can refactor.

I think there's something wrong with this patch. It's 324 kB (that's why it was
blocked on the mailing list).

Some files seems to have an entire copy of themselves added (not removed though,
in which case I would have suspected a line ending issue).

--

-- 
Arvid Norberg

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2

Re: Recording incoming connections

Ah, you're right.  Let's try that again...

On Fri, Sep 16, 2011 at 7:25 PM,  <arvid <at> cs.umu.se> wrote:
>
> I think there's something wrong with this patch. It's 324 kB (that's why it was
> blocked on the mailing list).
>
> Some files seems to have an entire copy of themselves added (not removed though,
> in which case I would have suspected a line ending issue).

------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2

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