[jdev] Different behaviors of ejabbered and openFire in pushing messages to the client!
sh at defuze.org
Tue Jun 19 03:28:08 CDT 2007
Thanks for this summary because I've been reading these sections of RFC
3921 *a lot* and there are so many different combinations that I lose it
/me pokes psa too. A diagram of all the different interactions would go
a long way /me thinks
Mridul Muralidharan a écrit :
> I think Peter is in the process of clarifying the bis spec on the
> subscription appendix's. /me pokes psa :)
> It might be a good idea to wait for that to be complete ... currently,
> the state of specs is a bit icky from an impl point of view (though
> well defined).
> Roughly, 3921 says these :
> - a user can add any contact to his roster, this does not trigger a
> presence subscription request - but a roster push(*) will occur.
> - a user can ask for subscription to contact : (if contact is not in
> the user's roster (step 1 omitted), it gets automatically added) this
> triggers a roster push(*) with change in subscription status (ask
> - if contact is online, subscribe is pushed to all available resources
> using rules similar to roster push(*).
> - if contact is offline or no resource is available which satisfies
> rule for roster push(*), this is stored for later delivery.
> - if contact rejects subscription (unsubscribed), this triggers a
> roster update in user's roster appropriately (must not result in
> removal of entry - I see that some servers remove the contact's jid
> from user roster) and a corresponding roster push(*).
> - 3921 says that the unsubscribed must be delivered to the user's
> (*) The roster push above will happen only to all resources which have
> requested (or modified) roster in some way (including asking for
> Similar steps above when contact's approves subscription.
> The state table related to inbound unsubscribe, unsubscribed and
> subscribed could be changed for 3921 bis spec (it has already been
> changed for subscribed). If I am not wrong, the last step above would
> not happen - that is, unsubscribe(d) will not be routed to the user.
> Here, I assumed that there is no subscription between user & contact,
> if that is present, it just adds more to the flow - refer to section 9
> in 3921 
> Hope this clarifies. The steps above are the same irrespective of
> whether it is a local contact, s2s contact, clustered configuration or
> other combinations.
>  http://www.xmpp.org/rfcs/rfc3921.html#substates
> Tran Thai Son wrote:
>> Hi all,
>> I am writing a client and I've experienced different behaviors from
>> different servers in handling client's actions such as add / accept /
>> deny subscription requests. What surprised me is that it seems there
>> is no standard behaviors ( e.g. processes of treating actions, order
>> of notification messages pushing to the clients...) for the server.
>> - ejabbered 1.1.3 always adds the incoming contact to the user's
>> roster (with the subscription status = 0, means no relationship)
>> before pushing the subscription (add-friend) request to the user. So
>> the client gets two messages: one to notify that there is an item
>> added, the next to notify that there is a subscription request.
>> - meanwhile, openFire 3.3.1 does not add the contact before, so you
>> get only the later message. One (probably) bug I found: even when the
>> client sent a message denying the subscription request, the server
>> still adds the contact to the user's roster (with subscription= 0)
>> Furthermore, with the same actions from the clients, the number and
>> order of messages that the servers send significantly different.
>> - ejabbered 1.1.3 tends to not to send any message to the contact
>> with subscription = 0. Example: If user B denied a subscription
>> request from user B (means no relationship at the moment), B will not
>> receive the next unsubscription request from A, but with openFire
>> 3.3.1, it will.
>> - Furthermore, I found the order of messages that openFire pushes to
>> the clients rather annoying. For example, if user A removes user B
>> from its roster (and therefore B will also remove A - my
>> implementation), A will receive "unsubscribed" and "unsubscribe"
>> (respectively) from B before received the notification that its
>> removal was done. So you cannot trust that: when you remove a contact
>> from your roster, you won't receive unexpected message from that
>> contact; You also see that contact still in your roster for a while
>> (with subscription = 0).
>> Does any body experience similar problems ?
More information about the JDev