Well, as for now I was unable to reproduce the
problem using my test installation. In addition our
client unfortunately requested that the
jabber-installation should be removed because of its
constant user mixup. So I dont have access to the
system that exhibited this behaviour.
Bummer. If you do ever get a chance to check it out let me know.
Are there any circumstances you could imagine the
server mixing up clients? e.g. same ip (doesnt apply
in this case), or no DNS-server …
There’'s no normal way this could be happening. However I can imagine several ways this could be happening because of a ‘‘mental model’’ mismatch. The XMPP (aka Jabber) protocol Messenger uses assumes user IDs of the form:
Where the ‘‘user’’ is the username of a unique account, and server must be the server hostname of the server (in the same way that email addresses work).
However, XMPP differs from most IM systems because it allows the use of resources (for example):
Allowing one user account (’‘user’’) to be logged in multiple simultaneous times (the ‘‘home’’ resource can be logged in, and the ‘‘work’’). Messages sent to user@server will automatically be sent to the resource with the highest priority (a presence option on most clients). You can force delivery of a message to a particular client by using it’'s full address user@server/resource.
So, it’‘s possible that people were logging into the same user account and (depending on the client’'s priority settings) messages may have been diverted to particular people in what seemed like random ways.
IIRC the client establishes a persistent TCP
connection to the server. In my way of understanding
the user should stay the same for every single TCP
connection. This would lead to the conclusion it
would be a server-side issue.
Yes. But as I said, the particular routing of messages to logged in nodes (client apps) can be affected by logging in with the same user account, but different resources (instead of using different user accounts). On a running Messenger system you should be able to check this by logging into the admin web interface, going to the session list, and seeing if the list looks like this:
Or more like this:
recommend using an external database for ‘‘normal’’
Well this was sort of an evaluation installation for
an small workgroup of 5 ppl using LAN.
I’'ll post here in case I reproduce this strange