Chatroom XMPP : retard de livraison de message / message receipt delay

:uk:/:us: Message template (english)

My YunoHost server

Hardware: Raspberry Pi at home
YunoHost version: 4.0
I have access to my server : direct access via keyboard and SSH
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no
If yes, please explain:

Description of my issue

Hi everybody !
I’ve got a strange issue when I use multi-user chatroom with XMPP.
When I send a message, other users receipted it hours later if they are not reading message in the chatroom.
We all use the android application conversation.

Is there any special configuration to be able to have a real time conversation ?

Everything works fine except chatroom

Thanks for your help!

Emmett


:fr: Modèle de message (français)

Mon serveur YunoHost

Matériel: Raspberry Pi à la maison
Version de YunoHost: 4.0
J’ai accès à mon serveur : En direct SSH
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Si oui, expliquer:

Description du problème

Bonjour Ă  tous,

Je me suis recemment mis Ă  utiliser les chatroom avec XMPP.
L’application que j’utilise coté client est l’appli conversation sur android.
L’orsque j’envoi un message, les autres utilisateurs mettent parfois plusieurs heures avant de recevoir le message, a moins qu’ils aillent voir si de nouveaux messages ont été postés.
Je n’ai aucun problème pour les discussions classique hors chatroom

Merci pour votre aide !

Emmett

@pitchoum une idée à ce sujet ?

Hello @emmett.

D’après ce que tu décris, je pense que les messages sont bien envoyés en temps réel mais que les participants aux chatrooms ne reçoivent pas de notifications pour chaque nouveau message.

De mémoire, dans l’appli Conversations (et c’est le cas dans d’autres applications XMPP), il faut explicitement activer les notifications pour chaque salon de discussion.
Pour les discussions “classiques”, les notifications sont automatiquement activées.

Hello !

Désolé pour le retour tardif.
Dans l’appli Conversations, les notifications pour les salons de discussion sont bien activées par défaut. J’ai controleé sur chaque client.

Je viens encore de faire l’essai à la seconde : j’envoi un message sur le groupe avec mon tel, j’attend 5 minutes, je controle sur le telephone d’un autre membre du groupe, rien dans les notifications. Je vais explicitement dans l’appli Conversation, et, au merveille, le message du groupe arrive enfin.

Je n’ai pas ce problème dans les discussions entre personnes.

L’appli conversations et bien démarrée en premier plan.

Une idée ?

En tout cas merci à toutes les équipes de yunohost! C’est un super projet !

Est-ce que ça se passe mieux si tu mentionnes le nom d’une personne dans le salon ? Est-ce qu’elle reçoit une notification ?

Juste pour être sûr : tu as bien vérifié dans Conversations que l’option de notification sur ce salon en particulier était bien “Notifier pour tous les messages” et non pas “Notifier seulement en cas de mention” ?

Bonjour !
J’ai essayé de mentionner le nom de la personne dans le salon, ça ne change rien.
Je te confirme que j’ai bien selecionné “notifier pour tous les messages”
Je te confirme également que dans les parametres de conversations, j’ai bien coché “service au premier plan / evite que le systeme ne ferme votre connection”

Je n’ai pas trop d’inspiration pour trouver une piste de solution

Est ce que le fait de ne pas avoir de certificat ssl sur muc.domaine.ltd peut avoir un impact ?

J’ai déjà noté des problèmes de retard de notification avec Conversations, mais je ne crois pas que ce soit lié à Yunohost dans mon cas. C’est pas très reproductible, j’essaierai de rapporter ici si je trouve qqc.

En essayant de reproduire le phénomène, je m’aperçois qu’il n’y a tout simplement pas de notification.
En fait, il faut que j’ouvre Conversations pour que la notification arrive.

Faut il activer XEP-0357 (push notification) ou quelque chose dans ce gout la ?
Il y a ce genre de ligne dans la configuration de metronome
"push"; -- Enable Push Notifications via PubSub using XEP-0357

Merci

Pour le moment toutes les notifs fonctionnent chez moi (conversation 1 à 1, groupe privé, salon public hébergé sur le serveur YunoHost).
Je suis en YunoHost 4.0.8, la version du paquet metronome est 3.14.1+ynh10-1, et dans la conf metronome j’ai bien le module “push” activé, pas chez toi ?
Sinon Conversations 2.9.0+fcr.

J’ai les mêmes versions installées…
Le module “push” est bien installé
XEP-0357 n’apparait pas dans la liste supporté par le serveur dans la configuration serveur de Conversations. Est-ce pareil chez toi ?

Je seche un peu. Je ne sais pas par ou chercher.
Ma config de métronome est celle d’origine

Chez moi la XEP-0357 apparait bien :

Visiblement un utilisateur peut demander au serveur d’arrêter les notifs; peut être essaye avec un nouvel utilisateur.

Dans mon cas, XEP-0357 apparait bien Ă©galement

J’ai fait un regen-conf pour voir si cela pouvait solutionner mon problème. Ca n’a rien changé.

Voici ma config :

   -- Generally required
            "roster"; -- Allow users to have a roster. Recommended.
            "saslauth"; -- Authentication for clients. Recommended if you want to log in.
            "tls"; -- Add support for secure TLS on c2s/s2s connections
            "disco"; -- Service discovery

   -- Not essential, but recommended
            "private"; -- Private XML storage (for room bookmarks, etc.)
            "vcard"; -- Allow users to set vCards
            "pep"; -- Allows setting of mood, tune, etc.
            "posix"; -- POSIX functionality, sends server to background, enables syslog, etc.
            "bidi"; -- Enables Bidirectional Server-to-Server Streams.

    -- Nice to have
            "version"; -- Replies to server version requests
            "uptime"; -- Report how long server has been running
            "time"; -- Let others know the time here on this server
            "ping"; -- Replies to XMPP pings with pongs
            "register"; -- Allow users to register on this server using a client and change passwords
            "stream_management"; -- Allows clients and servers to use Stream Management
            "stanza_optimizations"; -- Allows clients to use Client State Indication and SIFT
            "message_carbons"; -- Allows clients to enable carbon copies of messages
            "mam"; -- Enable server-side message archives using Message Archive Management
            "push"; -- Enable Push Notifications via PubSub using XEP-0357
            "lastactivity"; -- Enables clients to know the last presence status of an user
            "adhoc_cm"; -- Allow to set client certificates to login through SASL External via adhoc
            "admin_adhoc"; -- administration adhoc commands
            "bookmarks"; -- XEP-0048 Bookmarks synchronization between PEP and Private Storage
            "sec_labels"; -- Allows to use a simplified version XEP-0258 Security Labels and related ACDFs.
            "privacy"; -- Add privacy lists and simple blocking command support

            -- Other specific functionality
            --"admin_telnet"; -- administration console, telnet to port 5582
            --"admin_web"; -- administration web interface
            "bosh"; -- Enable support for BOSH clients, aka "XMPP over Bidirectional Streams over Synchronous HTTP"
            --"compression"; -- Allow clients to enable Stream Compression
            --"spim_block"; -- Require authorization via OOB form for messages from non-contacts and block unsollicited messages
            --"gate_guard"; -- Enable config-based blacklisting and hit-based auto-banning features
            --"incidents_handling"; -- Enable Incidents Handling support (can be administered via adhoc commands)
            --"server_presence"; -- Enables Server Buddies extension support
            --"service_directory"; -- Enables Service Directories extension support
            --"public_service"; -- Enables Server vCard support for public services in directories and advertises in features
            --"register_api"; -- Provides secure API for both Out-Of-Band and In-Band registration for E-Mail verification
            "websocket"; -- Enable support for WebSocket clients, aka "XMPP over WebSockets"

Ma conf metronome est identique.
Je suspecte vraiment Conversations, es tu en mode économie d’énergie ?
J’étais tombé la dessus https://www.hse-it.de/apps-android/quicksy qui dit visiblement que pour certains tel il faut forcer à ne pas optimiser la conso batterie pour cette app et forcer l’exécution en arrière plan.
Sinon peux tu essayer avec 1 (ou 2 comptes) fraichement configurés ?

A partir de deux téléphones, j’ai bien controlé dans la configuration android que l’app Conversations n’était pas optimisée pour la batterie : c’était bien le cas
J’ai controlé que l’app Conversations reste bien en premier plan dans les parametres de l’app : c’était bien le cas
J’ai créé un nouveau groupe juste avec ces deux téléphones : j’ai toujours le même phénomène.

J’ai remarqué que tant que l’application est bien en cours d’utilisation, même si je ne regarde pas directement la conversation du groupe, je reçois bien les messages.
Par contre, dès que l’application est en arrière plan et que je fais autre chose sur le téléphone, je ne reçois plus rien.

J’ai vraiment l’impression d’avoir fait le tour !

Ce problème n’existe pas dans les conversations classique entre 2 personnes.

Autre phénomène très bizarre :
Je prends mon téléphone et j’envoi un message au groupe
Comme d’habitude, pas de notification pour les autres.
Sur mon téléphone, je fais
GĂ©rer les comptes -> Clique sur mon compte -> Clique sur le petit crayon pour modifier mon nom -> je change mon nom et je clique sur accepter
Miracle : tout le monde recoit la notification

Je ne comprend pas pourquoi …
Si je veux que les autres recoivent la notification d’un nouveau message, il faut que j’aille modifier mon nom dans les paramètres de compte après chaque envoie :slight_smile:

edit : les autres participants recoivent également la notification si je redemarre le service métronome, et donc si je les force à se déconnecter puis se reconnecter au serveur

Salut Ă  tous,
Je viens de résoudre en parti mon problème en désactivant le module “stanza_optimisations”.

Je dis que la résolution n’est faite qu’en partie car je ne comprend pas quel est le problème avec ce module, dont je ne connais même pas précisement la fonction et le fonctionnement.

Si vous avez des idées, je suis preneur !

Visiblement ce module implémente les XEP-0273 et XEP-0352 qui précisemment permettent d’éviter d’envoyer du traffic vers les clients qui se sont déclarés “en veille”. Donc pour moi la question est bien, pourquoi ton client (Conversations) demande t’il à réduire ce traffic alors que tu n’es pas en mode économie d’énergie.
Je viens de voir qu’il y a une option dans Conversations : dans la rubrique Extensions :

Service en avant plan : Ă©viter que Android Conversations se ferme et coupe la connexion.

Est-elle bien activée chez toi ?

Sinon il semble que cette gestion de l’énergie peut différer entre les versions d’Android. Quelle version as-tu ? Chez moi c’est v7.1.

Merci pour ton retour !

Je ne sais pas ce qu’est la rubrique extension.
Par contre, lorsque je vais dans les paramètres, j’ai coché l’option “service au premier plan : evite que le système ne ferme votre connexion”

J’ai android 6.0 sur mon tel perso, et android 7.0 sur le tel d’un des utilisateurs du groupe. Les deux telephones ont cette option cochée.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.