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.
--
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:x...@jabber.ru.
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
_______________________________________________
