Why too many PEX messages?

Looking at the logger tab on my uTorrent 2.2.1 I see many messages along the lines of

"[2012-01-24 23:04:46] 98.232.170.128:59797(Modern Marvels): [Azureus 4.7.0.2 (100.0)]: Banning peer: too many pex messages. 5 since Tue Jan 24 23:04:16 2012"

- that's the last one in the log.

What does this mean? Is it detrimental to my pulling in the file?

Curious is all :)

cheers

BJ

same problem,means that any work that the creator sends out and is reworked you'll be stopped from downloading..KPP seeking an answer myself

Don't worry too much about that. Also, you may want to update to µTorrent 3.1.2 when the stable comes out, as several PEX-related things were fixed in 3.0.

I would worry about this, since I'm seeing the banned users most often using uTorrent 3.1.2 (same as what I use), and I'm getting this a _lot_ in the logs.

I would guess it has something to do with latency (my lines are quite full most of the time) and the PEX message being resent too many times, and when the latency finally catches on, the delayed messages finally get delivered all at once (none having been dropped as the sending client seems to have assumed).

Edit: I wouldn't worry about it as much if I was told for how long the peers were being blocked. Like, 5-15 minutes or whatever wouldn't worry me much, but what i'm currently being informed of makes me only assume they're permanently banned or some other excessively long time for a minor infraction.

I have been been downloading a big audio file and had 86% and it had 1 seeder who is on about 4 hours a day and another peer who had about 36% but with 10% i had not got so I was getting his upload and they were getting some from me. I noticed I stopped getting a download and uploading and saw they had the message about too many pex messages.

what you can do is right click on the file, select advanced then reset bans and hopefully it will all start uploading and downloading from the other person again

my question is can you set anything so it does not stop those with too many pex messages and also as they probably do not know whether they are sending too many pex messages how do i know that i am not sending too many pex messages and this is stopping me from from downloading.

I have an answer for PondPaul.

On Preferences expand the Advanced tab. Find the option "bt.ban_threshold". The value is usually set to '3'. If you wish to stop banning IPs for excessive pex messages, simply change the value to '10' or more. Although, I wouldn't raise it too high, as I am not aware of the consequences of receiving excessively large amounts of PEX messages.

Hope this helps.

I have an answer for PondPaul.

On Preferences expand the Advanced tab. Find the option "bt.ban_threshold". The value is usually set to '3'. If you wish to stop banning IPs for excessive pex messages, simply change the value to '10' or more. Although, I wouldn't raise it too high, as I am not aware of the consequences of receiving excessively large amounts of PEX messages.

Hope this helps.

http://en.wikipedia.org/wiki/Peer_exchange

It has been agreed between the Azureus and µTorrent developers that any clients which implement either of the following peer mechanisms try and obey the limits described below when sending PEX messages:

There should be no more than 50 added peers and 50 removed peers sent in a PEX message (so 100 in total).

In the case of ut_pex where there are different lists for IPv4 and IPv6 added peers, there cannot be more than 50 added peers in total. Same with removed peers.

A peer exchange message should not be sent more frequently than once a minute.

Some clients may choose to enforce these limits and drop connections which don't obey these limits. However, there should be some tolerance to clients that send a PEX message just under a minute since the last PEX message.

As PEX messages are packets of data.. (just to update peers) one could logically assume that getting too many of them too quickly would cause your network/downloads to fail as they are flooded out by the PEX message packets... one way to cause a DOS attack to utorrent users.

bt.ban_threshhold has no effect on "too many pex messages" bans on my system. I think that applies just to failed hash check bans. There really needs to be an advanced option to either increase the time period (from 60 seconds) or the number of messages allowed (5), both of which seem to be hard coded. Normally on healthy torrents the banned peers are not missed but on unpopular, hence unhealthy, torrents every seeder and uploading peer is precious. All of the ones I connect to are the latter and the banning cripples the struggling torrent. I don't see how 5 pex messages in 60 seconds could be seen as a denial of service attack. In any case I have to regularly unban because it seems the bans are permanent. Bury the setting in advanced preferences and the typical user won't touch it.

http://en.wikipedia.org/wiki/Peer_exchange

http://en.wikipedia.org/wiki/Peer_exchange

"A peer exchange message should not be sent more frequently than once a minute.

Some clients may choose to enforce these limits and drop connections from clients that ignore them."

The irony is that the majority of the offending banned clients are µTorrent 3.x ones. My own IP address is even sometimes banned by my µTorrent client (3.2.2). What's with that?

A search of the word pex here pulls up this problem for the last couple years and also seems to be related to ISP throttled peers. I just want the option to not ban them unless there is a legitimate flood (i.e., raise the threshold for banning).

The fact that µTorrent bans its own kind gives it away—this is simply a defect in µTorrent. We also do not need any advanced setting for this. We just need the defect to be repaired.

The hypothesis that the threshold is exceeded because of delays in the Internet connection, particularly under ISP throttling conditions, is intriguing. It would mean that the PEX messages accumulate in the throttling router's queue and are then released all in one go, thus exceeding the µTorrent threshold. This would mean that the receiving µTorrent does not see any PEX message in several minutes, and then suddenly sees the messages accumulated during these minutes all at once.

Therefore a better solution would be to look at the number of Peer Exchange messages over a longer time, like several minutes. A peer might be given an extra PEX message allowance for every minute during which it does not send any PEX message. An easier solution would be to simply raise the threshold.

Before programming such stuff, one should first ponder the thought what this threshold and banning is good for in the first place. Do we really have bad clients that send too many PEX messages? Why would they do that? What is the best way to cope with them, assuming they do indeed exist?

The fact that µTorrent bans its own kind gives it away—this is simply a defect in µTorrent. We also do not need any advanced setting for this. We just need the defect to be repaired.

And the fact that OTHER CLIENTS are also banned for excessive PEX messages suggest what to you???

That the same "defect" exists in all other clients that are totally unrelated to uTorrent other than they use the same protocol?

If you read and comprehend the PeX conventions, it states that a client should TRY to follow the agreed conventions. It is not a mandatory requirement or a precise timing to be adhered to.

The fact that µTorrent bans its own kind gives it away—this is simply a defect in µTorrent. We also do not need any advanced setting for this. We just need the defect to be repaired.

And the fact that OTHER CLIENTS are also banned for excessive PEX messages suggest what to you???

That the same "defect" exists in all other clients that are totally unrelated to uTorrent other than they use the same protocol?

I did not mean to say that the defect is to send too many PEX messages too quickly. The defect is that µTorrent punishes them for no good reason.

To me the observations suggest (a) that the defect is in µTorrent, and ( that the hypothesis (see my previous message) is correct. The defect is that µTorrent is too eager to punish other clients for apparent misbehavior.

If you read and comprehend the PeX conventions, it states that a client should TRY to follow the agreed conventions. It is not a mandatory requirement or a precise timing to be adhered to.

Yes, µTorrent is clearly going too far. Moreover, this case goes beyond "follow". µTorrent is trying to enforce the conventions by punishing seemingly aberrant clients. But it even punishes clients that follow the convention to the letter and do nothing wrong, because the implementation in µTorrent ignores the characteristics of the network, particularly that the Internet can have delays and its routers can have queues.

So it seems that it would be better if µTorrent tried to enforce the agreed conventions in a more intelligent way. In fact, in this case it would be better if it didn't try to enforce them at all.

Some clients may choose to enforce these limits and drop connections which don't obey these limits. However, there should be some tolerance to clients that send a PEX message just under a minute since the last PEX message.

So are you saying that you would prefer to have the uTorrent client use far more resources on the host machine to maintain lists of PeX messages from every job (not just the ones that active), connected clients and when a message was last sent to that client, rather than send the messages as and when received.

Doing that would use TEN TIMES (at least) the resources than the sponsored features that everyone whinges about.

I like hgmichna's suggestion to simply not enforce the limit at all rather than the current 5x tolerance which probably seemed more than generous when first implemented. Especially since any enforcement is optional according to the spec. If there is indeed a diabolical PEX generating program out there that could be used for a denial of service attack then there could be an advanced setting to implement a ban threshold for PEX messaging. I don't care how it is implemented but I would like some control of the banning tolerance.

… Especially since any enforcement is optional according to the spec. …

If the recent quote from the specs was correct, then not only is the enforcement optional, but the one-per-minute PEX message rule is also optional. This means that the current banning is totally outside the specification.

µTorrent banning other µTorrent clients for misbehavior is a joke anyway.

µTorrent banning other µTorrent clients for misbehavior is a joke anyway.

For me it's even worse.

1. My WiFi router gets banned over and over again on all torrents. But without any information in the log menu.

2. My IPv6 number get banned over and over. And almost no banned IPv6 numbers appear in the log menu.

I think it's about time this very annoying bug is fixed. I don't know what possible network problems they tried to solve with this "feature" but at least for me it's devastating.

If only I knew where the ban info is stored (it seems to live past a restart), at least then I could fix a script that deletes the sh*t every minute or so... :mad:

1. My WiFi router gets banned over and over again on all torrents. But without any information in the log menu.

2. My IPv6 number get banned over and over. And almost no banned IPv6 numbers appear in the log menu.

NEITHER of these are:

* Bad behavior

* Unintended

* Something where you don't want the bans to happen.

* Related to any other issues you're having

They both prevent wasted connection attempts trying to connect to yourself.

They both prevent wasted connection attempts trying to connect to yourself.

Ehhh???? How do you figure that? Why would banning my IPv6 number and the IPv4 number of my router prevent anything? Why does uTorrent even *see* any PEX messages from either one?

Nah, I (and obviously many more) still would like to know what disasterous network happenings banning IP-numbers that sent more than 3 PEX messages in one minute, is supposed to prevent and exactly what, in the specs, this "feature" is based upon.

The way it's all totally hidden and not configurable makes even people without tin-foil hats beginning to wonder...

The obvious response to this thread would of course be that the 3 pex per minute should be configurable. It seems like 30 pex per ten minutes would be more in line with Real Life.

But I guess that the uT people are simply doing their best to hunt away all the millions of people using uTorrent, and make them revert back to Azureus. If they can find it...

The obvious response to this thread would of course be that the 3 pex per minute should be configurable. It seems like 30 pex per ten minutes would be more in line with Real Life.

Better do not make it user-configurable, but configure it correctly in the first place. Yet another obscure setting is not good, because users will set it wrong.

It is also unnecessary. If it is configured correctly, nobody will have to change that setting.

It is also unnecessary. If it is configured correctly, nobody will have to change that setting.

Quite right!

When using the 'unban' command, I cannot see that the 'culprit' appears again immediately, which would suggest that your hhypothesis above is absolutely correct.

This is getting more and more interesting, the more you study the subject. From Wikipedia:

There are three incompatible PEX implementations

They are Azureus, BitComet and uTorrent PEX.

Now, if the uTorrent developers are childish enough to try to prove that the uT implementation is superiour, by banning the others, it seems like they are making a BIG mistake. Every single ban that I have studied so far (in the hundreds) have all been uTorrent clients. Not a single Azureus or any other client are accused of sending too many PEX messages.

The plot thickens... :cool:

PEX is supposed to, and I once again quote the Wikipedia article:

PEX greatly reduces the reliance of peers on a tracker by allowing each peer to directly update others in the swarm as to which peers are currently in the swarm. By reducing dependency on a centralized tracker, PEX increases the speed, efficiency, and robustness of the BitTorrent protocol.

It seems like the uT developers have missed something here, making PEX reduce the "robustness of the BitTorrent protocol".

So you'd rather spend about 20% of your bandwidth on PEX messages when you only need to use less than 0.1%?

Really?

There's no actual reason to send pex messages more than once every few minutes.

PEX doesn't actually help as much as DHT does either. PEX actually causes connection clustering, which is BAD for torrents.