powered by Jive Software

Jive + Jajc = users mixed up by client/server

Hi,

recently I installed Jive 1.0.8 + Jajc 0.0.7.106 (as recommended by the jive install howto) for a small workgroup of 5 ppl. DB is the one provided by Jive. Server is on Win2kPro.

Now users have been repeatedly complaining about their identities being mixed up in this constellation.

By example: A sends B a message but is reported to be user C.

I’'m trying to reproduce this on a test system, but i wanted to ask if this is a known problem.

Tnx in advance!

regards

Thomas

Hi,

This is definitely not a known problem. Let me know if there’'s anything I can do to help. I highly recommend using an external database for ‘‘normal’’ use. The embedded database is primarily for easy evaluation and demos of the product. An external database will be easier to manage, backup, troubleshoot, etc.

-iain

Hi

This is definitely not a known problem. Let me know

if there’'s anything I can do to help.

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.

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 …

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.

I highly

recommend using an external database for ‘‘normal’’

use.

Well this was sort of an evaluation installation for an small workgroup of 5 ppl using LAN.

An external

database will be easier to manage, backup,

troubleshoot, etc.

Yeah, that’'s clear.

I’'ll post here in case I reproduce this strange behaviour.

regards

Thomas

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:

user@server

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):

user@server/home

user@server/work

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

Yes.

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:

user1@server/work

user2@server/work

user3@server/work

Or more like this:

user@server/work

user@server/desk

user@server/office

I highly

recommend using an external database for ‘‘normal’’

use.

Well this was sort of an evaluation installation for

an small workgroup of 5 ppl using LAN.

Ok.

I’'ll post here in case I reproduce this strange

behaviour.

Great.

-iain

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:

user@server

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):

user@server/home

user@server/work

Just to clear things up:

I’'m pretty sure this did not happen. (But thanks for that suggestion. Willing to go in every direction to find the solution.)

I did set up all clients and the server myself. So hopefully no human error here.

Directly after setting everything up it seemed to work perfectly. All users were logged in. Everyone was able to chat with other ppl.

This effect started to occur the day after setup. I did not witness it myself. :[ - My coleague was on site. The only thing he tells me now about the situation was that the messages were all delivered to the right person, but the senders window showed a wrong name as a sender. (like my chatwindow showing me as being “iain”).

I must admit this now does clearly sound like a client problem. Don’'t know why they kept telling me the server was wrong. (L)Users…

I think we can close this topic now.

Thanks for the followup. If you do see it again, let me know and we can debug further.

-iain

I’‘ve seen this problem too now; I believe the problem is with JAJC client (jajc0.0.7.106). We’'ve used Exodus (exodus_0.8.6.0) and PSI (psi-0.9) with no such problems.

I’‘ve seen this problem too now; I believe the problem is with JAJC client (jajc0.0.7.106). We’'ve used Exodus (exodus_0.8.6.0) and PSI (psi-0.9) with no such problems.