Dotaz: Jabber ztrácí zprávy

[McDonald]

Omlouvám se že to píšu zrovna sem, ale nějaká sekce "ostatní" tu není.

Snažím se rodinu alespoň částečně odnaučit používat přežité SMS a nahradit je něčím normálnějším. Vybral jsem si XMPP/Jabber, protože to není služba, ale protokol. O co jde, no na Jabberu se ztrácí zprávy. Účty jsou zřízené na jabbim.cz. Když jsem připojený z mobilu a ztratím spojení, tak na ostatních klientech vypadám stále jako dostupný (někdy i třeba půl hodiny po výpadku), ale mě poslané zprávy mizí někam do /dev/null. Pokud jsem regulérně offline, tak zprávy odeslané v téhle době dojdou když se znova přihlásím. Xabber co mám na mobilu alespoň zobrazuje indikaci, že zpráva opravdu došla, ale v PSI+ to nikde nevidím. Ale stejně mi to přijde divné. Přece takhle by se zprávy ztrácet neměly. To je bug, nebo feature? A dá se s tím něco na straně klienta dělat?

---

---

Odpovědi

[KFC]

Ola, jabber nepodporuje potvrzovani zprav takze se ztraci (tusim exisuje nejake XMPP rozsireni) - jsou na to nejaky workaroundy, popr koukni na predchozi disukze tady na abc (vyhledavani na abc nefunguje, tak zkus google apod.) - uz se to tu resilo mockrat

[KFC]

jeste info k jabbim ;) - http://www.abclinuxu.cz/zpravicky/unik-hesel-z-jabbim.cz

[Jendа]

XEP-0198. Část serverů a klientů už to podporuje.

[luky]

jj, on jinak je taky problem v tom jak je vetsinou to posilani implementovane - server povazuje data za dorucena ve chvili, kdy se provede prislusny send/write/..., pritom by se server mohl tazat socketu, kolik dat bylo acknuto druhou stranou, a do doby nez je zprava acknuta na TCP vrsve ji povazovat za nedorucenou.

[pavlix]

Acky na protokolové úrovni jsou mnohem jednodušší a přenositelnější než hrabání se v TCP vrstvě.

[ET]

a funguje to spolehlive? dle predchozich diskuzi jsem mel pocit, ze moc ne

[pavlix]

Proč by to nefungovalo spolehlivě, stačí to mít implementované na obou stranách komunikace a mít to implementované správně. Je to docela jednoduchá věc, není na tom ani moc co zkazit. Jediný problém je v tom, že se zde bavíme o detekci, neexistuje způsob, jak doručit zprávu bez konektivity, takže ǰe důležité, co ten software udělá potom, tedy zda například tu zprávu podrží, informuje nějak uživatele, případně zda a za jakých podmínek se ji pokusí poslat při dalším spojení.

[Josef Kufner]

Pokud server i klient podporuje XEP-0198, tak se zprávy už neztrácí a spolehlivé to je. Co vím tak i vyladěnou podporu má ejabberd server, Gajim (Python+Gtk desktop klient) a Conversations (Android klient). Tito mají navíc i podporu XEP-0280 Message Carbons, takže pokud jsou oba klienti online, odeslané i přijaté zprávy chodí na oba a lze tedy klienty transparentně střídat v průběhu jedné konverzace. Navíc se vyvíjí i podpora XEP-0313 Message Archive Management, takže možná už brzy budou synchronizovány i offline zprávy mezi klienty.

XEP-0198 Stream management funguje tak, že pokud se ztratí spojení, tak se dalších pět minut udržuje session a veškerá komunikace jde do fronty. Pokud se během této doby spojení povede znovu navázat (odkudkoliv), klient může obnovit i celou session, obsah fronty se doručí a nikdo si ani nevšimne, že se spojení ztratilo. Klient je celou dobu vidět online a nikdo krom samotného klienta neví, že chvilku nebyl připojen. Tedy můžeš se vykecávat cestou v metru a ten druhý uvidí jen že píšeš nějak pomalu, akorát podle délek tunelů.

Pokud session vyprší, nebo je jinak zničena, obsah fronty se zahodí, ale nedoručené zprávy jsou uchovány, jako by klient byl od začátku offline, tedy po opětovném připojení klienta přijdou jako delayed delivery.

Pokud klient ztratí svou session (spadnul nebo byl ukončen po ztrátě spojení), při dalším připojení k serveru session neobnoví, ta je tím zničena a postupuje se stejně, jako když expiruje. Sestřelovat server jsem nezkoušel, ale to nenastává až tak často.

[ET]

OK, diky (i pavlixovi) za odpoved ;)

[petr_fm]

Jinymi slovy, zlate sms. Vyprdni se na jabber nez prijdes o nervy. Je to slatanina, ktera je prezita a dneska to nikdo nepouziva. Kdyby to fungovalo treba jako google talk, bylo by to super, ale takhle je to nepouzitelne. Chce to IM s bufferem zprav na serveru a komunikaci klient server, ne client to client.

ale nezbyva, nez si neco takoveho napsat sam.

[Jendа]

To je nějaký trolling?

Google Talk je Jabber, buffer zpráv přidává to XEP co jsem napsal výše a a klient-server Jabber je, klient-klient se používá jenom při přenosu souborů (a možná audia).

[pavlix]

Točí se to tu pořád dokola. Vždy se může stát, že se zpráva nedoručí z objektivních důvodů, a to bez ohledu na protokol. Je pravda, že u mnohých implementací protokolu XMPP se stává, že toto nedoručení není detekováno a tudíž o něm není ani odesilatel informován, ani nedojde k opětovnému pokusu při znovunavázání spojení.

Prostředky k tomu už dávno jsou, a to hned na několika úrovních včetně konkrétních rozšíření XMPP. Pokud na tom někomu záleží, je vhodné zatlačit na tvůrce implementací a později na provozovatele, aby pokud možno všechny články na síti zajišťovaly bezpečné předání zprávy o krok dál.

Jako náhrada SMS podle mě Jabber stačí. Tak jako tak je u SMS nutné počkat na manuální potvrzení příjemcem, protože ani takovéto klasické potvrzení nezaručuje, že zpráva došla až na jeho přístroj. Sám jsem se na koordinaci po SMS docela spálil.

Odpověď je, že se s tím něco dělat dá, ale musí se chtít.

[pavlix]

To nic nemění na tom, že sám SMS používám, protože je pro určitý účel považuju za nejvhodnější prostředek a rozhodně bych je nenazýval přežitkem.

[paul2no]

Trochu OT, ale mohl by mi někdo osvětlit, jak je možné že v základním XMPP chybí taková zásadní věc, jako je kontrola doručení zprávy? To je nějaký historický důvod?

[pavlix]

V té době to vůbec zásadní nebylo a nikoho to nezajímalo ani u ostatních IM.

[paul2no]

O jaké době se bavíme? Já jsem spíš mladší generace, takže opravdu nevím.

[Josef Kufner]

O době, kdy kabely byly k počítačům přišroubovány a ztráta spojení tak nehrozila.

[pavlix]

Ztráta spojení není běžná ani na domácí wifi, pokud člověk nechodí mimo signál.

[Josef Kufner]

No jak na které. Někteří mají občas nějaké to hluché místo někde. Ale o domácí WiFi nejde. To spíš třeba školní, nebo restaurace. A nebo taky nešikovně uspaný notebook.

[pavlix]

Nevím kolik škol a restaurací mělo v době návrhu protokolu wifi.

Na druhou stranu teď jsou ty rozšíření vyspecifikované už řadu let a tvůrci klientů nad nimi můžou stavět uživatelské rozhraní tak, aby člověk věděl, co se dostalo alespoň na server a tedy je připraveno k odeslání dál a stejnětak tvůrci serverů mají možnost zajistit opakované pokusy o doručení v případě, že se jim klient ztratil a znovu našel.

To, že to přišlo pozdě, nepopírám, a sám jsem se o to zasazoval snad aspoň rok před finálním schválením. Ale stěžovat si, že původní protokol obsahoval nepotvrzované zprávy, je podle mě nesmysl. Jednak se mohlo tehdy počítat s tím, že se to pořeší na úrovni TCP a nechtěli duplikovat jeho funkcionalitu, jednak s tím nemuseli počítat vůbec, protože ten problém v podstatě neexistoval. Jednak stoprocentní doručení nemuselo vůbec nikoho zajímat, vzhledem k tomu, že i tady se v podstatě řeší SMS jako alternativa.

[pavlix]

Mimochodem, malé logické cvičení...

Někteří mají občas nějaké to hluché místo někde.

Srovnej s...

pokud člověk nechodí mimo signál.

Člověk se tady sere s tím, aby psal komentáře neprůstřelné vůči hnidopichům a oni pak tu část stejně ignorují, protože by tím přišli o zábavu.

[Josef Kufner]

Tos mohl rovnou napsat, že spojení se neztratí, pokud se neztratí

Navíc ono ani nemusíš chodit mimo signál, stačí si sednou na místo s mizerným signálem a někdo ti pak zavře ty správné dveře.

[pavlix]

Tedy jinými slovy řešíš od začátku sračky.

[Josef Kufner]

Ty jsi si začal

[pavlix]

O době, kdy byl ten protokol navržen. Sám si pamatuju dobu, kdy jsem se zasazoval o schválení těch prostředků proti ztrácení zpráv a snažil jsem se vysvětlit ostatním, proč je plánované e2e potvrzování problém a proč je nedostačující a tedy proč je potřeba řešit potvrzování na úrovni spojení, jak ho navrhoval Justin. Na druhou stranu absence potvrzování zpráv nepředstavovala při běžném použití jabberu zásadní problém, to přišlo až při přesunu lidí na nestabilní mobilní připojení.