Openfire (ARCHIVED)
  1. Openfire (ARCHIVED)
  2. JM-14

Improve delivery strategy when connected from multiple resources

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 3.3.0
    • Component/s: Core
    • Labels:
      None

      Description

      If a user is connected multiple times using the same priority in different clients the server will send the message (sent to bare JID of user) only to the client that last logged in (with highest priority). Instead we need to be smarter and even let admins override the default logic:

      New smart logic:
      1) Select resources with highest priority
      2) Select resources with highest show value (e.g. available, away, xa)
      3) Select resource with most recent activity
      4) Send message to that resource

      Admins can set the system property "route.all-resources" to true to override the above logic and just send the message to all connected resources with highest priority.

      See: http://www.xmpp.org/specs/rfc3921.html#rules (Section 11.1.4.1.)

        Activity

        Hide
        added a comment -

        It would also be nice if you had an option to "deliver to a random server".

        Even better would be if there were affinity. So, imagine that A B and C are all connected with the JID "foo@example.com". If "dombiak@jivesoftware.org" were to send a message to "foo@example.com", it might randomly select B as the place to send it. Then, future messages from dombiak to foo would keep going to B for as long as B is still online (or until the session cache times out).

        That would allow load balancing for complex services.

        Show
        added a comment - It would also be nice if you had an option to "deliver to a random server". Even better would be if there were affinity. So, imagine that A B and C are all connected with the JID "foo@example.com". If "dombiak@jivesoftware.org" were to send a message to "foo@example.com", it might randomly select B as the place to send it. Then, future messages from dombiak to foo would keep going to B for as long as B is still online (or until the session cache times out). That would allow load balancing for complex services.
        Hide
        Raffi Krikorian added a comment -

        I would be interested in option 4: deliver to all the resources.

        Show
        Raffi Krikorian added a comment - I would be interested in option 4: deliver to all the resources.
        Hide
        Andreas John added a comment -

        Hello,
        I did set "route.all-resources true" via web UI -> Server -> Properties. And I did connect with two PSI Jabber clients successfully. But messages sent to me are not received in both clients. I think there is a bug in the override....

        rgds,
        derjohn

        Show
        Andreas John added a comment - Hello, I did set "route.all-resources true" via web UI -> Server -> Properties. And I did connect with two PSI Jabber clients successfully. But messages sent to me are not received in both clients. I think there is a bug in the override.... rgds, derjohn
        Hide
        Phil Stracchino added a comment -

        Better yet than "just send the message to all connected resources with highest priority": Since I don't know of a single XMPP client that allows the user to actually set (or even know) its priority, how about giving an option to allow a complete override and route to all connected resources regardless of priority? The reason I found this thread in the first place was a discussion with a colleague who was trying to find out how to do exactly that. He just wants to be able to send (or be sent) a Jabber IM and have it show up both on his desktop AND on his phone. Even with "route.all-resources=true", there's simply no way to do that at present, unless you can somehow arrange for your desktop and your phone to both have the same (and highest) priority — and honestly, with existing XMPP clients, you can't do that. I use three different XMPP clients (Xabber, Jabiru, and pidgin), and to my best knowledge, not even one of them so much as hints that the concept of priority exists, much less lets me know what my priority is — and god forbid I should be able to actually set it.

        Show
        Phil Stracchino added a comment - Better yet than "just send the message to all connected resources with highest priority": Since I don't know of a single XMPP client that allows the user to actually set (or even know) its priority, how about giving an option to allow a complete override and route to all connected resources regardless of priority? The reason I found this thread in the first place was a discussion with a colleague who was trying to find out how to do exactly that. He just wants to be able to send (or be sent) a Jabber IM and have it show up both on his desktop AND on his phone. Even with "route.all-resources=true", there's simply no way to do that at present, unless you can somehow arrange for your desktop and your phone to both have the same (and highest) priority — and honestly, with existing XMPP clients, you can't do that. I use three different XMPP clients (Xabber, Jabiru, and pidgin), and to my best knowledge, not even one of them so much as hints that the concept of priority exists, much less lets me know what my priority is — and god forbid I should be able to actually set it.
        Hide
        Phil Stracchino added a comment -

        Actually, let me amend that slightly: It was just pointed out to me where the priority setting is in Xabber, and I don't know how I missed it. I can't for the life of me find one in pidgin.

        Show
        Phil Stracchino added a comment - Actually, let me amend that slightly: It was just pointed out to me where the priority setting is in Xabber, and I don't know how I missed it. I can't for the life of me find one in pidgin.

          People

          • Assignee:
            Gaston Dombiak
            Reporter:
            Gaston Dombiak
          • Votes:
            9 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development