I am using openfire 3.8.0 as the server of an instant messaging application. I found that every time a client disconnects, the server will auto kick the client from every chat room it has joined in. Is there anyway to make chat room occupantship persistent?
Thanks in advance.
You mean you want for a user to stay in the room when he is offline? Well, i think this is against XMPP specs and you will probably need to use something else than xmpp server to achieve that.
I am quite confused. Which part of XMPP spec is against persistent occupantship? Could you please give me more details?
So, are we speaking about the same thing? “You mean you want for a user to stay in the room when he is offline?” If so, then http://xmpp.org/extensions/xep-0045.html
17.1.2 Ghost Users
Deployment experience has shown that sometimes a user can appear to be an occupant in a room even though the user’s real JID has gone offline since joining. Such users are called “ghosts”. To help prevent ghost users, a MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (in this context, the delivery-related errors are , , , , , and ). A MUC service MAY also use XMPP Ping [41] or similar methods to periodically check the availability of room occupants. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.
This suggests that offline (ghost) users should be removed from the room’s occupants list. And i think Openfire’s (and other xmpp servers’) MUC service is doing this. I haven’t ever seen offline users in the group chats.
Btw, if a client goes offline, what’s the point to keep it in the room? You can modify your client (if you can) to automatically rejoin rooms after reconnecting to a server.
I see. As for your concern about the use of persistent occupants, sometimes they are useful.
Chat room occupants may want to know what was said in the room during the time he was offline. Although rejoin will bring some chat history, but what if the number of messages he missed exceeds the number of chat history messages that was configured to send to newly joined occupants? Certainly some messages will not be seen by him.
In addition, the chat history presented may also contain many messages that had already been read, which may result in duplicate chat record on the client. Although it can be prevented by hard-coded filter on client side, but the effort can be readily saved if the server can provide persistent occupantship.
wroot wrote:
So, are we speaking about the same thing? “You mean you want for a user to stay in the room when he is offline?” If so, then http://xmpp.org/extensions/xep-0045.html
17.1.2 Ghost Users
Deployment experience has shown that sometimes a user can appear to be an occupant in a room even though the user’s real JID has gone offline since joining. Such users are called “ghosts”. To help prevent ghost users, a MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (in this context, the delivery-related errors are , , , , , and ). A MUC service MAY also use XMPP Ping [41] or similar methods to periodically check the availability of room occupants. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.
This suggests that offline (ghost) users should be removed from the room’s occupants list. And i think Openfire’s (and other xmpp servers’) MUC service is doing this. I haven’t ever seen offline users in the group chats.
Btw, if a client goes offline, what’s the point to keep it in the room? You can modify your client (if you can) to automatically rejoin rooms after reconnecting to a server.
Well, this is arguable. The server is already storing a history. So if a user is staying offline in the room, should a server start to preserve additional copy of history for that user alone? How can a server determine what part of the history has been already read or not? A user could be idle for a while and miss some messages and then connection brakes and he disconnects, then server pings that client, notices that he is offlien and starts collecting messages for him, but it will miss those supposedly read messages from the idle time. Then this user reconnects. How should a server determine whether it should serve a whole history or just a part? Granted it can be done with a lot of MUC service changes, additional checks, packets, etc. And it would create an additional load on the server and database (many history copies for every offline user). Btw, a client has some options about requesting the history (number, age also i think, etc.). It can’t determine what messages has been read either. And i think such history manipulation should be done on a client side. Server should handle basics which common users will need.
Well, I don’t think it necessary to store addtional history for individual room occupants in order to satisfy my requirement. When the server is dispatching group chat messages to occupants, it can monitor the result of message delivery. An IO exception will occur if the recipient is offline, then the server can notice that exception and store the message in the offline message queue of the user himself, which is the same place where offline single chat messages is stored. However, it seems that Openfire currently discard all the messages if delivery exception is encountered, and that’s why sometimes single chat messages will get lost, there has already been a post concerning this problem, which you may be familiar with since you are one of the participants. http://community.igniterealtime.org/message/228494#228494
You have opened an issue and it seems that someone is working on it, hope the issue will be resolved soon.
Yes, i’ve seen your comment there. Peer to peer messages are handled differently and MUC is a different beast in xmpp. Unless MUC XEP changes, i don’t think this would be implemented for group chats in xmpp servers’ core functionality.