Jabber/XMPP Clients supporting multiple connections (resources) per username

[GeekDrew]

We're using Openfire as a Jabber server at my office, and currently all of our clients are using Spark (both Openfire and Spark are from IgniteRealtime). In general, this arrangement works very well; we have Spark start on login whenever the user is a member of the appropriate security group, and it authenticates using Kerberos for SSO (Openfire's user database is Active Directory via LDAP), and the user therefore doesn't need to worry about any usernames/passwords/etc. We've been using this for over a year.

Now one of our courts would like to use this for their staff to communicate. The issue I see with this is that some users need to be able to simultaneously connect to the chat server from multiple workstations. For example, a bailiff generally has a PC in the court's administrative offices, and another PC in the courtroom. He needs to be able to be reached regardless of which PC he is currently sitting at; relying on that bailiff to remember to open Spark and re-connect whenever he changes PCs is unacceptable (as the bailiff doesn't log off/on of windows when he changes PCs; he simply locks/unlocks due to speed). The same situation exists with judges and some guards.

From what I've read, XMPP supports having users connect multiple times simultaneously by having each of the connections use a unique "resource" name. Spark, by default, uses "spark" as the resource name. Some other Jabber clients use the current machine's %computername% as the resource name; that's definitely preferable for me. I can install a different client on courtroom PCs, so that the user can connect using multiple computers at the same time... sort-of. They can log in, and other users are able to see their status at both PCs (for example, "(mch-00-01) Available" and "(hoj-04-02) Away due to idle"), but they can't direct an IM to a specific resource or to all resources -- the messages always seem to only go to the resource that the target user has most recently used, which defeats the purpose of all of this.

Does anyone have any advice/suggestions? I'll take whatever help I can get... I'm not having much luck with either Google or my own experimentation.

TIA.

 

[GeekDrew]

OK, well if nobody has any advice on that, does anyone have any suggestions for a different (free) client/server instant messaging environment that can support multiple concurrent users on the same account?

 

[acheron]

I could tell you how to write your own XMPP client that would do that. Unfortunately while I know quite a bit about the protocol and developing new software for it, I don't know much about actual released clients.

A project I was on used Openfire and Psi IM, I just tested it out with those and the same thing happened, with the message going to the most recently used resource. (=resource with highest priority)

You should be able to do that from either the server or the client, it just appears that that's not an option with Openfire (though I was using a rather outdated Openfire version). Some quick googling/reading makes it look like most servers are designed this way on purpose, assuming that sending the message to all resources is a bad thing. Openfire accepts plugins, you might be able to add the functionality to it that way.

Sorry I can't be of more help.

 

[GeekDrew]

Thanks for your input. Yeah, I've read specs, documentation on Openfire and Spark, etc. It looks like there is no reason that it *shouldn't* be possible, but developers just aren't doing it. From what I've read and in my opinion, what I'm trying to achieve should be a client-side issue. It makes perfect sense, from reading the XMPP RFPs and other docs, that the server is working correctly by determining priority and routing the message accordingly -- if no resource is specified. And it looks like the server is routing messages to the correct resource when a resource *is* specified. The problem is that I can't find any clients that allow the sender to select (via the GUI) which resource to communicate with. One resource - can't remember which - does allow the user to view the status of each resource, but doesn't allow the user to select the resource for use.

I'd just go ahead and write something (probably for Spark, since it has the best SSO integration) that would take care of my issues... but I don't know Java, and I suck at programming anyway.