[JDEV] MQSeries and Jabber

[David Waite]

Rahul Dave wrote:

> Currently, if one wants to multicast a message in jabber, dosent the client
> have to pull over the roster and send messages one by one to the server, which
> routes them?
>
> Does presence work in the same way? or can the server send the presence
> update to interested parties?
>
> Rahul

Eventually something sends the packet out to multiple recipients, but since the
client is bandwidth-limited (specifically to prevent spamming and some DoS
attacks), the best methods are done server-side.

Presence can be considered to be pubsub - the roster is an ACL for people allowed
to see a user's presence, as well as a list of things which you are subscribed
to:

subscription='to' or subscription='both' - you are supposed to be able to see
this user's presence.
subscription='from' or subscription='both' - you allow this user to see your
presence.

When a client comes online, it requests the presence for other entities, via
presence type='probe'. The server simply walks the roster once you send available
presence, asking each user (or more appropriately, the server handling the user)
for their presence. Also, the server walks your roster and sends presence to
everyone you indicated should receive it (by subscription ='from' or 'both').

After this, anytime the user sends a new presence state out without addressing it
to a specific JID, the presence is sent to all the users on the roster again.
This way, all users remain in sync with presence changes, pushing the data rather
than using some polling mechanism.

The one caveat is that a user can send any presence message to any JID; this is
not a broadcast mechanism. The users who have seen your presence are tracked, so
that if the client connection is disconnected abruptly, the users all get
presence type='unavailable'. All transports and components which use the user's
presence state use this feature to track if the user has an active session.

Another example would be a conferencing service (either using the 'old' groupchat
protocol or the 'not-quite-there' jabber conferencing framework specification in
draft). A user subscribes by joining a room; after that they receive messages
directed towards the room. The interesting thing about conferencing is that the
subscriber list is public (the list of participants in the room), and that it
provides an abstraction layer between someone's interest in a room (their
nickname) and their actual JID. This abstraction lets you interact with a single
person participating within the room, such as sending a 'private' message, as
well as with the group as a whole.

One of the discussions we had a while back on the JAM list was me talking about
pubsub and resource discovery, and how a conferencing service could be mapped
into such a scheme (rather than the other way - creating a conferencing service
and reinventing generic concepts). I thought it was quite interesting, but
unfortunately JAM is still too far on the horizon for me to push it :-)

Pubsub in a user-oriented system is a bit different than a closed
application-oriented system, in that you have to combat things like evil people
using your server for spamming. All the pubsub-like systems in Jabber have the
requirements (up to this point in time, at least) that users must opt-into a
subscription list themselves, and must be allowed to remove themselves from that
list.

-David Waite