[Standards-JIG] proto-JEP: Smart Presence Distribution

Michal vorner Vaner michal.vaner at kdemail.net
Thu May 18 12:00:23 UTC 2006


On Thu, May 18, 2006 at 01:05:45PM +0200, Carlo v. Loesch wrote:
> Dave Cridland typeth:
> | a) Worthwhile based on the cost of implementation. (Is this tricky to 
> | code right?)
> 
> no, it took us one hour because we already had the data structures
> in the right place, so all we added was rendering and parsing of the
> no-to syntax, and whoops it worked. we will have to retrofit it with
> placebo-to-syntax now.. ;)
> 
> all you have to code is, when receiving such a packet, to walk through
> your user list, pick out the ones that know the sender, and make sure
> they have properly legally subscribed his presence. if this operation
> is costy in your case, cache it. in our case we have such "context
> receiver lists" for both presence and groupchat anyway, and they are
> created as users login and join groups. in PSYC, presence, groupchat
> and newscasters are all derivates of the abstract 'context' concept.
> they use a common syntax for distribution, applicable to any message
> type. in other words you can even send messages to your presence channel,
> just like myspace bulletins. the /shout command delivers your message to
> all of your friends using the same multicast context as for presence.

However, there are servers which do not allow this too easilly. I will
be only guessing now, but I can not imagine how hard it would be for
jabberd to do it. Jabberd is split into many separate processes, one of
them is router, one handles c2s connections, on handles s2s connections
and so on.

I do not know, where is the place it should be handled and, preferably,
how it would get there. The router decides by the to attribute. So it
would have to be probably rewrittent to something, I do not know what,
when it arrives in s2s. Which would mean more parsing, some guesswork
and anything.

> | b) Worthwhile based on the cost of deployment. (Is this going to cost 
> | CPU, memory, etc?)
> 
> this varies depending on the architecture of your server.
> keeping a list of pointers to user objects per sender shouldn't
> be a big issue.
> 
> | c) Worthwhile based on the detrimental effects to security. (Is this 
> | handing over responsibility for policy to a foerign domain?)
> 
> opinions on this vary a lot, as we have seen.
> would be useful to have some facts and figures.
> guess we can only find out by running a little
> test network using this approach.
> 
> | d) Worthwhile to do now, or should we be concentrating on simpler 
> | methods first. (The "low hanging fruit" argument).
> 
> this is low hanging fruit. other approaches require more work.

As I have said before somewhere, I found easier to get it all, I guess.
Or I hope so. I will write some kind of JEP once I have time (in a week
I should have). So just an overview:

It would be based on advanced addresing jep.

It would extend it by lists and a way to construct them, save them,
modify and copy.

It could be further extended using some kind of automated lists. This
would allow, if needed in future, to add support for lists created by
roster and be modified without sending any filters, privacy lists (yes,
you would have to do remove from the list, but noone will ever know, for
what reason it is there)

Yes, it would be slightly larger, but if I consider the normal size of
presence stanza, it would be better to use it even for two same stanzas
with sending the addresses. Later on, you could just reuse the addreses.

It could be used for any presences and messages (even for MUC, or
anything that is here or will appear in future), it could use the same
list for presence and messasges in MUC and so on. Further, the MUC
component could just remove the dupliciting code, as well as presences
and so on and it would be all done by only one dupliciting code, which
could just use remote dupliciting components with lists to rely on.

It could be used by clients as well, as few are implementing
multi-recipient messages and many more want to.

I guess using this approach, there would be less work total, since the
same mechanism and code would be shared between all types of the smart
casts and if there is any advanced addressing component coded already,
it could be reused.

> | Any real-world compression algorithm will reduce the complete 
> | collection of jids by a significant amount because they're 
> | self-similar, containing a significant quantity of repetitive, and 
> | thus redundant, data. This is basic information theory stuff.
> 
> good, still everyone running a larger service agrees jabber has some
> serious scalability issues. is compression already in place, or is
> something keeping you from switching it on? i know our server supports
> some, but i don't know if we are actually using it for xmpp.. fippo?
> fippo is the man who wrote the jabber server in psyced, i'm just the
> guy who comes up with the multicast ideas and the core of psyced.  ;)
> 
> well compression is always appropriate with xml, so if it's not in
> use yet, you should certainly start doing so, soon. our JEP will
> then help reduce the traffic, if necessary. would compression also
> solve all issues related to pubsub traffic?
> 
> | Of course, you shouldn't let the facts get in the way of an 
> | opportunity to express your undoubted wit.
> 
> well many of us here have this sort of glorious ability.  :)
> 
> | By the way, I'd drop that sarcastic tone about the "placebo to", as 
> | well, because I'm not clear it's redundant in the case where several 
> | domains are hosted on the same server. Besides which, whatever the 
> 
> in the current architecture of jabber a new tcp connection is created
> for every domain a host has, and within that tcp connection the stream:to
> says which hostname the communication is directed to. leaving out the
> 'to' would simply mean, that the 'stream:to' is intended.
> 
> | technical issues, logistically it's too difficult to remove in 
> | specification.
> 
> i was told an update to XMPP is in the making anyway, so it okay
> to suggest changes that would be reflected in a new RFC. but huh
> it's just second hand information and i may be wrong.
> well i don't care, i already added the redundant 'to' to the JEP.
> 
> | PS: It's not "typeth" - that's second person singular archaic. The 
> 
> oh dear, i haven't known this in the past dozen years i use that
> word in my replies..  ;)
> 
> 

-- 

Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060518/241b2417/attachment.sig>


More information about the Standards mailing list