On Fri Aug 27 10:00:07 2010, Evgeniy Khramtsov wrote:
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.
There are always attacks like this. A malicious user can generate
thousands of fake resources without PEP, and you still need to track
them in order to do presence optimization.
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.
So you're snooping all messages even from remote sources to guess if
they're PEP events intended to be filtered? How would you know? If I
(or my client) explicitly subscribes to a particular node on
PEP/PubSub-onna-jid service, you'd filter it out anyway.
3) for S2S users a server sends PEP message blindly to bare JID. In
fact this doesn't even violate the XEP :)
I'm struggling to understand how that does not violate the XEP?
auto-subscribe is defined as a depth=all items subscription to the
root node from the bare_jid, and filtered-notifications then only
sends the notifications to those full jids that have requested them.
Both are required for PEP. I don't see how you can claim to be
conformant to PEP without doing both.
So because you filter on the subscriber's end, you restrict
PubSub-onna-jid to the PEP subset, and because you don't filter on
the service end, you break even that if the subscriber isn't on
ejabberd.
So you end up with a interop matrix like:
Subscriber ->
v Service ejabberd Standard
ejabberd PEP No
Standard PEP Full
I don't see why you think this is a good thing.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________
