Wenn XEP-0198 und XEP-0199 mal nicht reichen

Der Ein oder Andere wird es vielleicht kennen. Der Gesprächspartner wird als Online angezeigt, OTR-Nachrichten kommen aber – aus welchen Gründen auch immer – nicht an. Normalerweise sorgen die Erweiterungen XEP-0198 (Stream Management) und 0199 (Ping Support) für einen sauberen Nachrichtenaustausch. Zusätzlich sorgen sie auch dafür, dass der Server die Information erhält ob ein Client online oder offline ist.

Was ist aber wenn diese Erweiterungen nicht vom Client unterstützt werden?

Dann kann es zu dem oben beschriebenen Fehler kommen. Der Gesprächspartner ist offline, der Server hat es nicht gemerkt und ihr seht den Gesprächspartner weiterhin als online. Nach einem Hinweis eines Nutzers, der Dank geht hier an DLQ, können wir nun auch für diese Situation eine Lösung bieten. Heute haben wir den Prosody eigenen Mod, Mod_Pinger, installiert und aktiviert. Dieses Modul macht nichts anderes als im Abstand von 30 Sekunden einen Ping an jeden Client zu senden. Sollte der Client daraufhin nicht antworten, wird er von unserem Server als Offline markiert.

Euer Jabber.de-Team

17 Gedanken zu „Wenn XEP-0198 und XEP-0199 mal nicht reichen

  1. Nette Änderung. Wo ich mich jedoch jetzt sorge ist, erhöht das im Endeffekt den Akkuverbrauch auf Smartphones? Und jetzt sind Einstellungen wie der “Herzschlaginterval” in Chatsecure auch recht nutzlos? Dort kann man angeben, dass zum alle zwei Minuten der Server aktiv benachrichtigt wird. Da Wakelooks unnötig Akkuenergie ziehen können, müsste ich die Wochen mal beobachten ob sich das deswegen jetzt verschlechtert (bei mobilen Geräten ist das wirklich kritisch – am Desktop ja überhaupt kein Thema). Eine Einstellung mit alle 60 Sekunden wäre dann eventuell passender. Ich hoffe ihr bleibt da am Ball! 🙂 Danke

    • Also bisher konnte ich bei Conversations keine Probleme in dieser Richtung feststellen.
      Sollten allerdings Beschwerden reinkommen – werden wir das natürlich anpassen! 😉

    • Ich weiß nicht, was dieses Herzschlagintervall bei Chatsecure ist, ich vermute mal, es handelt sich hierbei um TCP-Keepalives. Diese sind eigentlich dafür gedacht, um bei (sehr langer) Funkstille Änderungen der Routen zwischen zwei Teilnehmern zu bemerken.
      Aus wikipedia:
      “Keepalive time is the duration between two keepalive transmissions in idle condition. TCP keepalive period is required to be configurable and by default is set to no less than 2 hours.”
      Daran kann man schon erkennen, dass das für unseren Anwendungsfall nicht die optimale Lösung ist,
      Der Akkuverbrauch durch den Mod_Pinger dürfte nicht auffallen,
      nach meinen Praxistests sind die 30Sekunden scheinbar auch eher das Timeout, nicht der Ping-Intervall. Dieser liegt (empirisch) bei ca 5min idletime. Zumindest wird ein Verbindungsabbruch jetzt nach spätestens ca 5min bemerkt.

  2. Und eine Frage nebenbei. Unterstützt ihr den Profilbild Bildupload bei eurem Jabber Server? Egal welchen Client ich benutze, das Bild sehen andere dann nie. Umgekehrt sehe ich auch Bilder von anderen Kontakten nicht. Das der Dateitransfer über Jitsi nicht funktioniert oder der Dateiproxy in Miranda NG nicht, finde ich auch noch merkwürdig, was bei anderen Servern keine Probleme macht. Zum Glück geht der Transfer immerhin über “In-Band Bytestreams”.
    Danke für eure tolle Arbeit bisher! In der Zeit wo euer Server online ist, ist der Jit.si Jabber Server dann schon 6 – 7 für längere Zeit mal offline gewesen. Bei solchen Ausfällen macht es unfreiwillig dann den Eindruck, dass Jabber zu unzuverlässig ist oder ein “Spielzeug” wäre, wenn ständig Server down gehen. Zum Glück ist das bei euch nicht so! 🙂

    • Ja, Profilbilder werden unterstützt und funktionieren auch ohne Probleme.
      Das Thema mit dem Dateitransfer ist bekannt – aber liegt meist an den Clients (wobei es bessere Wege für Filetransfer gibt als einen Messenger!)

    • Das mit den Profilbildern kann eventuell daran liegen, dass es dafür zwei unterschiedliche Standards gibt.
      Zum einen ist das der vCard-Standard, die meisten älteren Clients unterstützen nur diesen.
      Daneben gibt es noch den moderneren PubSub-Standard; Conversations unterstützt beispielsweise nur diesen.

  3. Ich habe von diesen Dingen (XEPs) nicht so viel Ahnung, aber es wird immer auf MAM (XEP-0313) hingewiesen, welches wohl die Möglichkeit bietet, Nachrichten auf dem Server zu speichern bis der andere wieder online ist. Wäre es vielleicht möglich, dies auf jabber.de zu aktivieren? Auch XEP-0352: Client State Indication wäre vielleicht ein weiteres Feature, welches hilfreich in diesem Zusammenhang wäre.

  4. Habe gerade gesehen, dass das mam-Modul erst ab Prosody 0.10 läuft, zur Zeit aber noch 0.9.8 die aktuelle stabile Version ist (und die habt ihr auf jabber.de ja auch am Laufen). Vermutlich müssen wir also auf Version 0.10 warten….

    Vielen Dank auf jeden Fall für Euren Service!

    • Dem Vorschlag möchte ich mich anschließen. Das Modul implementiert XEP-0363, eine XMPP-Erweiterung die meiner Meinung nach schon lange überfällig war 😉

        • Wenn man die Files aber z.B. bei Conversations mit OpenPGP verschlüsselt werden, ist es doch fast egal, ob jemand diese verschlüsselte Datei sehen kann oder nicht. Nicht verschlüsselte Nachrichten, die erst später von der Gegenseite empfangen werden, liegen ja auch unverschlüsselt auf dem Server.
          Bitte verbessert mich, falls etwas falsch ist

          • Ne passt alles – aber die Bedenken bleiben.
            Ich werde auf der Startseite in den kommenden Tagen eine Umfrage dazu starten.

          • Das ist auf jeden Fall ein netter Gedanke.

            Aber…
            a) Ich denke, dass die wenigsten OpenPGP für ihren Jabber-Client nutzen. Es ist viel praktischer (einfacher für die breite Masse) OTR zu nutzen.

            b) Das Nachrichten bis zur Zustellung auf dem Server bleiben stimmt, da die meisten wohl OTR nutzen, spielt das eine eher untergeordnete Rolle. Zusätzlich kann man aus einer Nachricht keinen Zusammenhang für einen kompletten Nachrichtenaustausch (Inhalt) ableiten.
            Ich bin mir jetzt nicht sicher wie 0363 das löst. Verbleiben die Files dauerhaft auf dem Server?

            c) Wie sieht es hier rechtlich aus? Wird Jabber.de dann zum Filehoster?

            Das sind die Punkte die mir dazu spontan einfallen und warum ich mich persönlich dagegen aussprechen würde.

            Mit Conversations und OTR lassen sich prima Dateien austauschen, warum also Files auf fremden Webspace, unverschlüsselt auslagern?

            Güße
            Steff

        • Wie’s aussieht werden alle über HTTP-Upload geteilten Dateien automatisch verschlüsselt auf dem Server abgelegt. Zumindest mit Conversations und aus OTR oder OMEMO verschlüsselten Chats heraus. Der zufällige AES Schlüssel wird dann per #anchor in der URL mit dem Chatpartner geteilt. Solche anchors werden nie an den Server übertragen sondern werden nur lokal beim Empfänger zum Entschlüsseln verwendet.
          Siehe Source:
          https://github.com/siacs/Conversations/commit/ec0aff4ed7982cc6db43cb6337f828f732429fd2

          Schade dass XEP-0363 diese Verschlüsselung nicht explizit spezifiziert, aber hoffentlich findet sie Verbreitung im Angesicht von Conversations als bisher einziger Referenzimplementierung.

  5. Hä hä! Klasse dass das mal jemandem aufgefallen ist. Was jetzt noch nett wäre: Pro nicht beantwortetem Ping ein XMPP Stanza an die Clients in der Kontaktliste schicken, so dass diese ein entsprechend negatives Symbol (nach dem Motto: “Contact has bad connection” / trauriges Smiley… Scheißhaufen etc.) einblenden können 🙂
    Durch solche Features wird Jabber echt effektiver. Danke! 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.