Route.all-resources simply doesn't work as it should

Openfire Openfire Support
1

It’s been brought up back in year 2009 and apparently within almost 5 years this has not been fixed.

I set route.all-resources to true in the console, restart the Openfire server.

All my clients have a priority of 1.

I login, don’t send any messages and have people spam me, nice! I recieve all the spam messages on all 3 of my clients.

The moment I reply to one, then from thjat point forward, until i logout of all 3 and relogin and remain inactive on each, the messages only arrive inbound on that window.

I can force it to work by Sending an IM to “username@domain/*”. In the logs it shows I sent a message to that address, but after replying and trying again, the bare jid has now become a full JID with the resource username@domain/fasjklfh

So, does this work? What must someone do to recieve messages on all resources?

http://issues.igniterealtime.org/browse/OF-29

This ticket is unresolved in the unable to reproduce status… It’s extremely hard to believe you could not reproduce this.

It’s simple.

Set all your priorities the same. Send a message to a user logged into multiple areas. Does he recieve the messages on all his logged in clients? Ok, great. Now, tell him to reply to you on ONE of the clients. Then go ahead and try to reply back to him again. Your new messages will only arrive on one if his clients after he replies.

This is stupid in order for someone to recieve messages on all clients, he must login and remain idle. The moment one of his clients sends a message, or is detected as not idle, that is the client that messages will go to.

So many people making complaints about the same issue…I can’t believe you couldn’t reproduce this… Also, I am not about to go telling everyone in the office to send messages to "bob@chat.domain.com/*" because that’s ridiculous. Why is OpenFire removing the bare JID? I am tempted to make a youtube video.

Woiuld anyone have this working as it should? (i.e. all messages delivered to all resources…no matter what?) Which clients are you using? Thanks for any help.

2

I thought you would push your comment to the older thread, which is linked to the ticket. Anyway.

That’s how i see this (i’m not a developer and don’t know all XMPP specifications, but based on comments in previous discussion by developers like Guus or rcollier or there http://community.igniterealtime.org/thread/38398

ClientA sends a message to bare jid. Server receives it and checks if route.all-resources property is enabled. Otherwise it would use its internal logic to deliver the message (resource with most recent activity probably if there are a few connected resources with the same priority). When this property is enabled, it checks all connected resources, finds the highest priority and sends the message to all resources with this priority.

So, on the other side ClientB1 and ClietB2 receive that message. ClientB1 responds. I think that a client forms a packet which includes a full jid of ClientA, not a server manipulating the packet. Server delivers this response to ClientA. ClientA responds seeing that a resource of ClientB1 is in the packet, so it sends its respond to ClientB1 resource, not to a bare jid.

Server receives this message and sees that full jid is specified. By XMPP specifications server MUST deliver a message to a specified resource, not to all resources. So server omits the route.all-resources property in this case. I think this is intended and correct behavior, that’s why the ticket has been closed with “Cannot Reproduce” resolution. Though maybe “Not a bug” resolution would fit better, but there is no such in the system.

Again, i’m not a developer, so not sure, but probably a client can be modified to always send messages (even replies) to bare jid, so then it should work with route.all-resources. Though i see not much use of only incoming messages syncing between resources. You would talk to someone on one client and then find all incoming messages on all other resources, but without your own replies. Probably a server can also be modified to not obey XMPP specifications. Maybe even a plugin would work, though it may need lower level interaction with server than a plugin can have. This is open source, so you can change the code or find someone to change it for you and create your own version of server or a client. But this will not be included as a core feature.

1 Like
3

wroot explains it very well. The only problem here is that the task was not closed with Not a bug.

The behaviour being asked for would in fact be a new feature that specifically violates the specification. I can’t say whether that should be added or not, but it does certainly keep popping up.

4

People need this new feature. Can we pay someone to develop it?

5

Thanks for the detailed explanation. That explains the frustration that myself and others have bee having with this feature not working as expected (by the admin/end user) – makes perfect sense.

6

This is not just the case of paying someone to do this. Specifications do not have such functionality and Openfire wants to be standards compliant (well, not by itself, but the developers who contribute to this project want i suppose). Maybe specifications will change/improve in the future. Some work has been done and there is already a support for syncing the outgoing messages. Though i know only one client supporting it, and it’s an android one (Yaxim). Things are moving slowly, so i wouldn’t expect for this to appear in the near future.