Peer Exchange with Azureus

[FMF_Man]

Hey all, I'm working on a custom plugin to get Azureus and uTorrent talking with one another. What I'd like to do is be able to send and receive uTorrent PEX packets from my Azureus client. Without good documentation on the uTorrent PEX protocol, I've been struggling through communicating with a typical uTorrent client. I have a few questions:

First off, is it even possible for an Azureus client to exchange PEX packets with uTorrent, or will uTorrent just ignore those packets?

Secondly, other than the uTorrent handshake (which I have drawn out below), what kind of initialization do I need to do in order to actually send and receive Peer Exchange packets?

Finally, I seem to be getting disconnected from the peer after about 5 minutes, is there a way to avoid the idle timeout without actually downloading anything (as I want to keep the peer around to obtain more peers), or should I initiate a transfer in order to keep my peers?

Any answers you guys have to my somewhat detailed questions will be immensely helpful. Thanks a ton!

-Frank

uTorrent handshake (as far as I can tell):

4 bytes: packet length (0x36)

2 bytes: indication of uTorrent handshake (0x14 0x00)

a b-encoded dict with the following entries:

{

e = 0

m = a b-encoded dict with the following:

{

ut_pex = 1

}

p = port_number

v = uTorrent 1.5

}

[osm0sis]

From what i understood, the Azureus devs would only have to update to the extended message format in order for µT and Az to PEX. I don't know why they haven't bothered with it yet, but a few other client programmers seem to think it's a good idea. One which i mentioned in the DHT compatibility/KTorrent thread is MooPolice. Hideous client but one of the first to implement full µT PEX support. Info and source can be found here: http://139.30.204.74:83/forum/viewtopic.php?t=44

[Ultima]

http://www.azureuswiki.com/index.php/Enhanced_messaging_protocol

I think the ball's in the Azureus devs' hands, as that's what µTorrent supports, and it was supposed to supersede the current messaging protocol in Azureus a LONG time ago.

[FMF_Man]

Cool, these sources should help me immensely. I got tired of waiting for the AZ Devs to do it, so I figured I'd write one myself, if I had known about MooPolice earlier, I could have been done long ago. I'll repost later if I have any further questions. Thanks again for your help.

-Frank

[Firon]

The enhanced messaging protocol link in the wiki is broken...

[FMF_Man]

Given the libtorrent source, I'm fairly sure that I'm sending packets in the correct format. However, I'm still having trouble staying connected to uTorrent peers. What I'm curious about is uTorrent's built in 5 minute idle timer. Meaning, when a peer has been idle for 5 mins, they are disconnected from the peer list. I would like to remain active in a uTorrent peer's list without needing to actually download pieces from them (mostly for the purpose of building my peer list). Do I need to send piece requests to the peer in order to stay active, or is there some other way of staying active (I've sent keepalives as well, but those don't seem to affect the situation).

[Ultima]

Increase peer.disconnect_inactive_interval to whatever you want in seconds.

[FMF_Man]

That would work on the uTorrent side, but I mean as someone trying to connect to a uTorrent peer, what can I do (other than initiate a download) to keep my connection active in the uTorrent peer's eyes?

[Ultima]

Hm...? What do you mean? Setting peer.disconnect_inactive_interval to say... 6000 means that µTorrent will not, on its own accord, disconnect from that peer for 100 minutes. At that point, only thing it's up to is the peer on the other side of the connection to try to maintain the connection, not µTorrent, as µTorrent will not disconnect on its own until the threshold of 6000 seconds has passed.

[FMF_Man]

What I mean is that I am not running uTorrent, I'm running Azureus, and I'd like to keep my connection to a uTorrent peer as "active" so that the connected uTorrent peer doesn't drop me. So what I'm wondering is what you mean by "it's up to is the peer on the other side of the connection to try to maintain the connection, not µTorrent". What is it I have to do to maintain the connection (and I'd like to avoid actually downloading pieces, for now)?

[Ultima]

Oh, I'd misinterpreted it as you connecting to yourself for testing, but I guess that couldn't happen anyway... erm... I thought you could send keepalives...? That's what think I was told the inactive timer on the Peers tab counted by anyway =T

Edit: Actually, re-reading my documentation, it seems the inactive timer resets only upon µTorrent receiving the last non-keepalive message. So it seems you probably do have to transfer data.

[FMF_Man]

OK, now we're getting somewhere

I'm going to start by simply requesting a piece with a 0 offset every so often to see if that helps me maintain my connection. More info when I get it.

Thanks again for your help!

-Frank

[FMF_Man]

I think I may be getting ahead of myself at this point. Some quick captures with WireShark reveal that my point of failure is not actually the 5 minute timeout issue. It seems I'm failing sooner than that in one of two places:

1) when I send a request for a piece

2) when I send my second or third PEX packet

I guess I have a couple questions then:

What is the piece request size that uTorrent accepts (or shouldn't it accept all piece request sizes)?

What are the requirements/limitations when it comes to sending PEX packets?

[osm0sis]

well well well.. decided i'd snoop around on the Azureus SF page and forums and found this tidbit.

to save people the trouble of reading through:

drevilxxl: PEX is not compatible with Azureus because they haven't changed to the new enhanced messaging protocol.

the8472: there is no enhanced messaging protocol yet, it's still in an early draft phase. The only messaging protocol that's currently deployed is Azureus'.

so i guess there's your answer on the Az team's apparant lethargy. They don't believe they have anything to do.

[FMF_Man]

Yeah, as I said, I got tired of waiting for these guys to get their stuff together. I'm developing this completely on my own. Currently, it's just to see whether or not I even can, hopefully I'll be able to use it in the client to actually increase my connectivity.

[osm0sis]

right on. how is it coming along anyway?

just my 2 cents, but i think you should just make it function like a normal PEX supported client should and not worry about keeping your connection with the µT peers open. You get your peers after the PEX has been established in the handshake and then you probably get other µT users in the PEX and then the cascade effect of peer lists coming to you from all the different users should be fine.

if you lose connection with a peer and then they reconnect again there's probably another peer list exchange that takes place, so it's no great loss. i guess what i'm trying to say is please make it conform to the norm and not abuse anything.

[FMF_Man]

That's actually exactly what I have going now. I'm confident that my handshakes and PEX messages are in the correct format, and I'm currently testing out the effectiveness of everything I've been doing here. I'll keep you posted on the actual impact on # of peers when I can, but work is really picking up for me as well, so further development on this may be sparse. More info when I get it. Thanks for all your help, btw.