[jdev] The future of Jabber/XMPP?

Evgeniy Khramtsov xramtsov at gmail.com
Fri Aug 27 04:00:07 CDT 2010

27.08.2010 02:47, Dave Cridland wrote:
> On Thu Aug 26 15:41:29 2010, Evgeniy Khramtsov wrote:
>> Lots of bugs in PEP server implementations are because the XEP itself
>> is written poorly. It doesn't scale: the idea of keeping resources
>> and features of every user from every server on the planet is
>> completely insane. Don't be surprised if you see memory leaks - they
>> are by design :)
> Well, I agree it's pretty easy to "leak" subscriptions (we[1] do,
> sometimes, if we never see an unavailable from a resource). That's our
> bug, and we'll be sorting that one out soon. Otherwise I don't think
> there's anything that inherently has a leak associated with it - even
> including the fact you gradually learn about every feature of every
> client, it's simply not that big a deal.

There is also a possibility where a malicious user can generate 
thousands of fake resources with different caps/features which you 
should also track. A server should also have a protection against this, 
especially if it is a small server.

> Honestly, I don't find PEP too much of a pain - it does have a memory
> cost, but it's really not astronomical, and the benefits are very nice
> for clients and users.

We choosed another approach in ejabberd, where we don't store anything 
except of caps_hash->features hash table. If you are wondered:

1) caps_hash->features table is only for *local* users. The overhead is 
really small for obvious reason.
2) since we already store local user's presence in C2S state (this is 
MUST in RFC), a server filters out *every* outgoing PEP message (based 
on caps from user's presence and features from caps_hash->features 
table) right before sending the message to the local user. No memory, no 
cpu overhead here.
3) for S2S users a server sends PEP message blindly to bare JID. In fact 
this doesn't even violate the XEP :)

So I suggest adding two "SHOULD" statements in the XEP:
1) a server SHOULD filter PEP messages before sending it to local user.
2) a server SHOULD broadcast bare PEP message to all available local 
user's resources.

Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.

More information about the JDev mailing list