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

[Tran Thai Son]

Thanks for the information, too.
Now all we can do is to make the client as fault-tolerant as possible :)

On 19/06/07, Sylvain Hellegouarch <sh at defuze.org> 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.
> >>
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20070619/75a1bac5/attachment-0002.htm>