10
votes

Comment garder la salle de discussion de groupe (MUC) existant tout le temps même s'il est déconnecté du serveur XMPP?

Je développe un module de message instantané (partie de l'application Web J2EE) à l'aide de OpenFire / JSJAC dans le protocole de XMPP (Jabber).

Les utilisateurs / groupes de groupes OpenFire / Tables ont été redirigés vers nos tables de base de données professionnelles, ce qui signifie que je n'ai plus besoin de maintenir des utilisateurs / des groupes dans Openfire. Tous les utilisateurs / relation de groupe ont été définis dans la base de données des affaires.

ci-dessous est l'image que je dessine sur le volet principal en fonction des besoins. En raison de ma faible réputation, je ne peux pas poster une image, donc je poste une URL pour l'image de mon UI de mon instantMessage. Désolé pour le peu avocat. InstantMessage Main UI Image

Vous pouvez voir que dans le volet de gauche, il n'y a pas de liste d'utilisateurs / groupes. Il y a des sessions sauvegardées en fonction de l'historique, qui me soupliez spécialement sur le groupe. J'ai lu le "XEP-0045: chat multi-utilisateur" de XMPP.org. Je connais le flux de travail général sur le chat de groupe: xep-0045: chat multi-utilisateur "

  1. Créez la pièce, produisez la Roomjid.
  2. Configurez la pièce. (Chambre réservée)
  3. Obtenez les utilisateurs de la base de données Business et Bind (ajouter) les utilisateurs à la nouvelle chambre créée.
  4. Envoyer un message à la pièce.
  5. service envoyer un message à tous les membres du groupe.

    Et savait qu'il y a du type de chambre est salle persistante est expliquée comme " une pièce qui n'est pas détruite si la dernière occupant sort; Antonyme: Chambre temporaire. " par doc. Et dans le même doc, certaines phrases ont dit:

    Un propriétaire de la pièce doit pouvoir détruire une pièce, surtout si la chambre est persistante. Le flux de travail est le suivant:

    1. Le propriétaire de la chambre demande que la salle soit détruite, en spécifiant éventuellement une raison et un lieu alternatif.
    2. La chambre supprime tous les utilisateurs de la salle (y compris les informations appropriées sur l'emplacement alternatif et la raison de l'être enlevé) et détruit la salle, même si elle était définie comme persistante.

      Après avoir lu la phrase ci-dessus, je suis plus perplexe, il y a plusieurs problèmes que je suis toujours confus.

      1. Quel est le sens des "sorties des occupants"? Si un occupant déconnecte du système (hors ligne), est-ce que signifie "exist". Et tous les occupants sont hors ligne, c'est que signifie que le "type persistant" rendra la pièce que nous avons créée tenue existant? Alors, où les informations de la chambre sont sauvegardées? dans Openfire ou quelque part autre?
      2. suppose que tous les occupants existent (hors ligne), Althrough Cette chambre créée n'était pas appelée, que diriez-vous des informations contraignantes? Je veux dire supposer qu'un utilisateur a reçu l'adhésion par le propriétaire (admin), si cet utilisateur existe ou hors ligne, la salle persistante gardera son rôle d'adhésion, non? En d'autres termes, tant que la pièce n'est pas destinée, toutes les informations de configuration et de liaison ne seront pas perdues, non?
      3. Que diriez-vous de la situation que le serveur OpenFire Rencontrer le redémarrage, que la salle créée et ses informations soient toujours là?
      4. Comment retrouver la pièce créée si le propriétaire se connecte? En sauvant l'ID de pièce?

        Outre la question ci-dessus, je pensais que le flux de travail réalise la MUC avec une pièce persistante. Voulez-vous vérifier cela et voir quel problème existait dans le flux?

        mon flux de travail pour la muc avec salle persistante

        1. Le propriétaire envoie un objet de présence au serveur pour créer la salle et donner à la salle Jid et définir l'ID de la pièce.
        2. Le propriétaire Envoie un objet IQ au serveur pour configurer la salle créée et définir le type de pièce comme "persistant".
        3. Le propriétaire envoie un objet IQ pour accrocher d'autres utilisateurs le rôle d'adhésion. (Info contraignant)
        4. Le propriétaire Envoyer un message objet à la salle Jid et la salle JID transmettra tout le message à ses membres contraignants.
        5. membres communs de cette salle de la pièce Message (Recevez) et obtenez la salle Jid et ID de la chambre (J'espère que tous les utilisateurs, y compris le propriétaire, peuvent utiliser cette pièce d'identité pour retrouver la chambre quand ils relogin ..)

          Donc, quel que soit le rôle, le propriétaire ou le membre commun, comment reculer et rejoindre la pièce créée en fonction de la salle Jid ou de la pièce d'identité avec une condition préalable que le type de chambre est "persistant" ??


0 commentaires

3 Réponses :


2
votes
  1. La spécification dit "Doit pouvoir détruire", pas "doit détruire". Mucs persistants ne pas se détruit automatiquement lorsque le dernier utilisateur quitte le MUC

  2. Je dépend de la mise en œuvre du composant MUC. Si cela stocke les MUC persistants sur le stockage persistant, il est possible de recharger toutes les MUC persistantes sur le redémarrage. IIRC le composant MUC de Openfire le fait.

  3. Rendez-le persistant.


1 commentaires

4. Comment retrouver la pièce créée si le propriétaire se connecte? En sauvant l'identifiant de la pièce?



0
votes

Vous devez mettre à jour le code Java dans Openfire afin que les groupes ne soient pas supprimés si l'utilisateur se passe hors ligne. Vous devez mettre à jour le code contre MUC dans OpenFire


1 commentaires

Pouvez-vous s'il vous plaît aidez-moi à fournir le code de MUC à Openfire. Merci d'avance!



0
votes

Je vous suggère de regarder la nouvelle fonctionnalité XMPP de Muclight.

Cela compose de multiples fonctionnalités, tout comme WhatsApp et à ce que vous attendez.

La persistance est traitée dans ce type de groupe de muclight.

XMPP sur le serveur de Mongooseim : https://mongooseim.readthedocs.io/fr/Latest/open- Extensions / muc_light /

XMPP sur ejabberd serveur : https: //www.ejabberd .im / Aggregator / Catégories / 2


0 commentaires