[jdev] Different behaviors of ejabbered and openFire in pushing messages to the client!

[Sylvain Hellegouarch]

/me waves at Peter!

Peter Saint-Andre a écrit :
> All will be revealed in rfc3921bis. :)
>
> But I need to finish my edits to rfc3920bis first...
>
> Soon.
>
> /psa
>
> Sylvain Hellegouarch wrote:
>> 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 quickly.
>>
>> /me pokes psa too. A diagram of all the different interactions would 
>> go a long way /me thinks
>>
>> - Sylvain
>>
>> Mridul Muralidharan a écrit :
>>>
>>> Hi,
>>>
>>>   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
>>> attribute).
>>>
>>> - 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 
>>> resources(*).
>>>
>>> (*) The roster push above will happen only to all resources which 
>>> have requested (or modified) roster in some way (including asking 
>>> for subscription).
>>>
>>> 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 [1]
>>>
>>> Hope this clarifies. The steps above are the same irrespective of 
>>> whether it is a local contact, s2s contact, clustered configuration 
>>> or other combinations.
>>>
>>> Regards,
>>> Mridul
>>>
>>> [1] 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.
>>>>
>>>> E.g.:
>>>> - 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.
>>>> E.g.
>>>> - 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 ?
>>>>
>>>> Son.
>>>>
>>>>
>>>>
>