Jabber - otevřená komunikace

12. 7. 2007 | Pavel Šimerda | Různé | 11715×

Jabber (XMPP) je otevřený komunikační protokol, který se používá především pro posílání "rychlých zpráv" (Instant Messaging). Přečtěte si o jeho výhodách a nevýhodách.

Nedávno jste měli možnost si přečíst článek o (v místních podmínkách) nejpoužívanější síti pro rychlou internetovou komunikaci a jejích úskalích. Většina problémů je společná všem uzavřeným sítím, je proto potřeba hledat alternativu mezi službami založenými na některém z otevřených protokolů. Při výběru protokolu je důležité dbát na propojení mezi různými poskytovateli, možnost propojení s dalšími sítěmi a atraktivitu služeb pro uživatele. Podíváme na jednu vcelku nadějnou alternativu k uzavřeným sítím – Jabber (standardizovaný pod názvem Extensible Messaging and Presence Protocol – XMPP).

Trocha historie

Jeremie Miller začal pracovat na Jabberu v roce 1998. Po čtyřech letech vývoje aplikací a protokolu (rok 2002) vznikla XMPP WG, která měla za úkol upravit původní Jabber protokol do podoby mezinárodního standardu IETF. Výsledkem práce této skupiny jsou specifikace RFC 3920 (XMPP Core) a RFC 3921 (XMPP Instant Messaging and Presence) z roku 2004. Většina práce na XMPP v současné době probíhá v jednotlivých rozšířeních protokolu (XMPP Extensions). Připravuje se i upřesnění základního protokolu.

Otevřenost, interoperabilita

Jako IETF standard má Jabber (XMPP) dobrou pozici jak v internetové komunitě, tak mezi společnostmi, které nepotřebují udržovat monopol udržováním svých zákazníků stranou od okolního světa. Za zmínku stojí například Google Talk, Gizmo Project, Livejournal Talk a také český server Jabbim.

Jednou z nejzásadnějších vlastností Jabberu je automatické propojení serverů v případě, že spolu chtějí jejich uživatelé komunikovat. Provozovatelé serveru se nemusí na peeringu jednotlivě domlouvat, servery se vzájemně vyhledají pomocí DNS, podobně jako v případě e-mailu.

Architektura, decentralizace

Jednotlivé servery jsou připravené se mezi sebou v případě potřeby spojit. Každý z nich obhospodařuje své uživatelské účty a připojené uživatele. Pokud některý ze serverů ze sítě vypadne, ostatní fungují dál, stejně jako u mnoha jiných technologií na Internetu. Protože jsou vaše údaje a seznam kontaktů uložené jenom na serveru vašeho poskytovatele, musíte si při přechodu jinam znovu přidat své kontakty.

Některé služby na Jabberu nezajišťuje server sám. Službu má na starost externí komponenta, která není závisná na konkrétním použitém serveru. Uživatel může využívat služeb libovolného serveru nebo komponenty, pokud mu to daný server dovolí.

Protokol, bezpečnost, spolehlivost

Protokol je založený na XML proudech (XML streams) a hojně využívá prostory jmen (XML namespaces). Tím usnadňuje tvorbu oficiálních i místních rozšíření. XML proud se běžně navazuje pomocí jednoho TCP spojení, které se udržuje, dokud je potřeba. Mezi alternativní možnosti patří přenos přes HTTP Polling (opakované HTTP dotazy) a HTTP Connect (dlouhodobé HTTP spojení). Ty se používají v případě, že z nějakého důvodu nelze použít běžné TCP.

V případě TCP spojení se datový tok zpravidla šifruje pomocí TLS, obsah komunikace znají v ideálním případě jenom uživatelé a servery. V případě, že chcete zabezpečit komunikaci více, můžete šifrovat zprávy pomocí PGP. Pak by měla být komunikace čitelná jenom oběma koncovým uživatelům. Mnoho klientů takto šifrovat zprávy umí.

Spolehlivost doručení zpráv není u komunikačních protokolů na bázi TCP běžná. Při pádu spojení se stává, že nevíte, jestli zpráva došla nebo nedošla. V případě Jabberu tento problém řeší nedávné (zatím experimentální) rozšíření pro potvrzování zpráv.

Kromě autorizací pomáhají vaše soukromí chránít seznamy blokovaných uživatelů (privacy lists), které vám umožňí vyladit nastavení soukromí podle vašich představ.

Některé z těchto funkcí s sebou pochopitelně přinášejí nárůst datového toku, což může být nepříjemné zvlášť pro uživatele, kteří platí přenesená data (například GPRS). To je možné řešit vypnutím některých funkcí nebo zapnutím komprese přenášených dat.

Stabilita

Přestože decentralizovaná síť z principu nepadá, může mít uživatel problémy s nestabilitou serverů poskytovatele, kterého si vybral. Možnost vybrat si jiného poskytovatele nebo postavit vlastní server znovu ukazuje na výhody otevřené decentralizované sítě.

Jednou z nejstabilnějších IM služeb, které si můžete vybrat, je Google Talk. Bohužel mu chybí některé pokročilejší funkce Jabberu, ale třeba to časem napraví. Pro české uživatele je velmi zajímavý Jabbim, který je dlouhodobě stabilní. Nedávné výpadky byly pravděpodobně způsobené přetížením databáze ze strany ICQ transportu při výpadcích serverů AOL. Během přetížení byla vidět snaha provozovatele problém co nejrychleji vyřešit. Přesto se občas se člověk musí rozhodnout mezi špičkovou dostupností na jedné straně a bohatými službami, podporou v češtině a k tomu slušnou dostupností na straně druhé (Google Talk vs. Jabbim).

Služby na Jabberu

Veřejné Jabber servery se liší rozšiřujícími službami, které nabízejí. Na vlastním serveru máte možnost přidávat služby instalací serverových komponent.

Nejčastější službou jsou konference (chatrooms) a brány do jiných sítí. Brány do uzavřených sítí vyžadují vaše přihlašovací údaje pro danou síť, aby se mohly vaším jménem připojit. IRC brána se používá stejným způsobem jako jiná konference. SMS brána umožňuje přidávat si do seznamu uživatele mobilů. SMTP brána zpřístupní vaše Jabber ID jako e-mail, zprávy vám pak chodí na Jabber.

Další zajímavou službou je Jabber disk, který umožňuje - mimo jiné - publikování souborů na webu. Příjemné jsou i televizní programy, jízdní řády, předpovědi počasí a další rychlé informační zdroje. Zvlášťě se hodí při přístupu z mobilního telefonu. Uživatelům Jabberu můžete zpřístupnit vlastní služby bez ohledu na to, přes který server se připojují.

Blízká budoucnost, P2P

Pro náročnější výměny dat mezi uživateli se více hodí přímé spojení, které si klientské aplikace přes server jenom domluví. K tomu slouží (zatím experimentální) rozšíření s názvem Jingle. Za pomoci Jingle se užitečnost Jabberu rozšíří na další sféry komunikace, včetně telefonování, videokonferencí a dalších datově náročnějších aplikací.

Jen si ještě budete muset počkat na jeho doladění a implementaci v rozšířených Jabber klientech. Zatím se hodí spíše na vyzkoušení a experimentování než nějaké velké nasazení.

Aplikace

Jabber klienty najdete na všech běžných platformách a prostředích. Mezi desktopové klienty z grafickým rozhoraním patří například Psi, Gajim, Tkabber nebo víceprotokolové Kopete a Pidgin (dříve Gaim). Na konzoli pustíte například GNU Freetalk. Z webových stojí za zmínku JWChat, Muckl (jen anonymní vstup do konference) a služba Meebo. Na mobilu můžete používat Bombus. Jen pro doplnění zmíním ještě Mirandu a Trillian, které si získaly oblibu u některých uživatelů Microsoft Windows.

Mezi oblíbené Jabber servery patří klasický jabberd a jabberd2, na velkých serverech oblíbený ejabberd a javovský Openfire (dříve Wildfire). Všechny tyto servery se dají vylepšit externími komponentami.

Problémy a nedostatky

Na drobné problémy jste mohli narazit v průběhu celého článku. Nic není dokonalé, Jingle mohl být dávno hotový, poskytovatelů by mohlo být více, s lepšími službami, stabilnějšími servery, atd. Přesto to nevypadá, že by Jabber v nějaké oblasti, kromě VoIP (kterou snad rychle dožene), výrazně pokulhával za ostatními. Spíše naopak.

Výraznější nevýhodou je snad jenom menší rozšířenost oproti ICQ v ČR nebo MSN ve světě, ale za to návrháři protokolu a tvůrci softwaru nemohou. Navíc to není nic, co by se nemohlo změnit.

       

Komentáře

[DjAARA]

Tak trochu PR na Jabber, ale proč ne…

[nescius]

ono to je těžký žejo, tyhle stránky jsou de-facto reklama na gnu/linux a oss, jabber respektivě xmpp je otevřený standard pro im takže vážně proč ne, reklamu to potřebuje! hodně zajmavej klient je coccinella http://thecoccinella.org/ - jeden z prvních klientů s funkčním VoIP a(!) whiteboardem - sdílenou plochou na kreslení :D mám v plánu spustit vlastní jabber server (je nainstalovanej, chybí ještě integrace s LDAPem) a vyhodit icq transport, zjistil jsem že 1/3 lidí v rosteru má jabber, a zbytek stejně jenom prudí ;)

[pavlix]

Zahození ICQ transportu už mám za sebou... a na coccinellu se určitě ještě podívám.

[pakanek]

Zase?
...porad zapominam vyznam zkratky PR.

[David Watzke]

Pakistan Railways.

[Karel60]

Na diskusích nevystačíš s jedním slovníkem zkratek. Na radioamatérském webu např. PR znamená PacketRadio. Mně se však stále pletou zkratky PR a RP (registrované partnerství).

[lizard]

Kdyz uz zminujete komercni firmy co podporuji Jabber, proc nezminite firmu Apple? S kazdym pocitacem Apple dostanete se systemem Mac OS X IM program iChat, ktery plne podporuje Jabber. A Mac OS X Server obsahuje iChat Server, coz neni nic jineho nez Jabberovy server.

[pavlix]

Dobrá připomínka... moc jsem se soustředil na linux a opensource distribuce.

Ale je fakt, že když už jsem zařadil Mirandu a Trillian, tak jsem Adium mohl dát taky.

[cezz]

Pekny clanok, hlavne pre zacinajucich uzivatelov (neviem do akej miery sa tito vyskytuju na abclinuxu.cz..), hoci sam by som ho (byt autorom) smeroval skor na technicku stranku veci, ktora by myslim tunajsich citatelov oslovila, pripadne mozno viac prakticky orientovat.

Ja len dodam, ze taky Pidgin ma zatial minimalnu (ziadnu) podporu transportov, co nemusi byt az taky problem, pretoze transporty pridane pod inym klientom by mali ostat funkcne aj nadalej.. Snaha toto nejako riesit priamo v Pidginovi je IMHO dost minimalna, kedze je to trochu proti koncepcii multiprotokoloveho IM. (je mi jasne ze transporty nemusia sluzit iba ako brany do inych sieti)

A tiez na zaklade mojich skusenosti mam taky pocit, ze v oblubenej Mirande na win je jabber dost problemovy (aspon co sa tyka konferencie).

BTW Bombus rulez - najlepsi mobile java IM klient, co som mal tu cest pouzivat.

[Robo]

S transportami su len problemy, do Gaimu(Pidginu) by to bolo implementovat zbytocne. Ja som mal s transportami v Jabberi vzdy len problemy, preto pouzivam Gaim/Pidgin. Inak konecne nejaky rozumnejsi clanok, nie len stale ze "ICQ je shit prejdite na Jabber" :)

[Václav HFechs Švirga]

Mi transporty dva ICQ účty a jeden na MSN fungují bez větších potíží už rok, co to bylo konkrétně za problémy?

[cezz]

Na druhej strane, ako som uz povedal, nie vsetky transporty su len do inych sieti. (napriklad tv program a podobne..)

[otaznik]

technicka stranka veci..nevim jak moc by melo smysl sem prepsat nektere z vyse zminenych RFC =) a clanek by tim byl zbytecne dlouhy (muj nazor, nejsem autor).

[cezz]

No ano, ale 110-ty krat citat, ze jabber je decentralizovany a ma transporty je asi tiez trochu zbytocne. Pod technickou strankou veci si predstavujem napriklad konfiguracia jabber servera a podobne.

Tiez by mozno bolo zaujimave okomentovat par JEP.. Napriklad

[pavlix]

Za to stodesáté čtení o transportech a decentralizaci se omlouvám. Na druhou stranu kdybych to vynechal, objevily by se komentáře, že mi to tam chybí.

Většina XEPů moc komentářů nepotřebuje, jsou psané hezky a srozumitelně. A jejich seznam na xmpp.org obsahuje i popisy, k čemu který XEP slouží.

Nejvíc komentářů by si zasloužily XEPy okolo Jingle, ale do toho se asi nikdo nebude chtít pustit, dokud to neuvidí v plném provozu a mezi různými klienty.

[Věroš]

Pokud bude pokračování, tak bych ocenil něco o provozování Jabber serveru - který vybrat, nevybrat, jak to je náročné a tak.

[Tomáš]

Připojuji se. Taky bych ocenil takový článek.

[pepik]

Další zájemce o toto téma

[Vykook]

A další....

[madA]

take bych mel zajem ;)

[frEon]

a dalsi

[:)]

taky bych to ocenil :)

[pavlix]

Hmm, to zní zajímavě :). Uvidíme.

[Ilfirin]

Článek jsem očekával v podobě jakéhosi povídání, tak jsem byl (příjemně) překvapen množstvím technických detailů.
Ale stejnak si myslím, že se o těch službách dalo povídat víc (takzvaně to trochu rozkecat, místo toho aby se jen řeklo že jsou a že se takto jmenují).

[hwsoft]

Primarne pro ceskoslovenske uzivatele je tu novy otevreny jabber server LINJAB. Mame domeny linjab.cz, linjab.net, linjab.org a linjab.sk. Server je fyzicky umisten na siti FreeNet Liberec v Liberci a je pripojen do NIXu pres zalohovanou optickou linku.

V nejbilizsi dobe budem rozjisdet i linjab.czf pro cleny ze site CzFree.Net, kde je server pripojen do peeringove centra NFX

[vain]

Pokud jde o tu podporu audio rozhovorů, jak to bude Jabber řešit? Nejsem moc informovaný v těchto věcech, ale Skype to řeší těmi tzv. nody, že někdo kdo má veřejnou IP adresu dělá spojovatelku těm co nemají, jak to tedy bude řešit Jabber třeba při komunikaci dvou lidí bez veřejné IP? Nebude to navíc moc zatěžovat server?

[Ilfirin]

Pokusí se to ustanovit přímé spojení. Ale ne vždycky to bude možné a jaké je pak náhradní řešení, to nevím.

[vain]

No právě, já si to taky nedokážu moc představit a hlavně se bojím aby to moc nezatěžovalo samotný server, no asi se budu muset poohlédnout po dokumentaci Jingle.

[Ilfirin]

Ono za určitých podmínek je možné ustanovit P2P spojení i mezi lidmi co nemají veřejnou IP.
Ve Windows je velmi známý software Hamachi, který právě toto dělá.
Akorát k tomuto propojení je potřeba třetí člověk s IP. Ten jen ustanoví spojení (ano, to je jabber server), samotná komunikace přes něj nepůjde.
Ale jak je řečeno. Se správnými NATy toto nebude fungovat. Taky si budu muset přečíst, co pak Jingle dělá dál. Těmi správnými NATy myslím firemní sítě. V domácích prostředí to bývá takřka bezproblémové.

[vain]

Mě tak napadlo že u oficiálních programů ICQ5.1 třeba, resp. při posílání souborů mezi těmito klienty to jde bezproblému i u dvou co nemají veřejnou IP adresu. Na mirandu například může bezproblémově přijímat většinou pouze ten který IP adresu veřejnou má. Takže ICQ5.1 (nebo 6 asi taky) to nějak tak řeší, tak bych předpokládal, že tak nějak by to mohl řešit i Jabber. Pokud teda je to u toho ICQ přímé ten přenos souborů. Ale to jsou takové ty moje spekulace, jestli někdo má lepší nápad potažmo tomu lépe rozumí... poslouchám =)

[pavlix]

Jabber to řeší.

Zatím to řeší pomocí data proxy, časem se na to bude pravděpodobně používat Jingle (a data proxy by mohla zůstat jako alternativa).

Bohužel ne všechny aplikace to umí bez zásahu uživatele (nastavení data proxy), ale technicky to není problém.

[David Jaša]

Tipuju to na omračování NATů pomocí STUN.

[pavlix]

Bude to pomocí ICE (RFC nevímkolik)... které stun podle mě používá.

Takže se dá říct, že máš pravdu.

[jiri.b]

podporou IPv6? :)

jezis uz je na case vyhodit to obstarozni IPv4 a ty prezitky, ze NAT je dalsi security!

[pavlix]

Jistě, IPv6 na všech stanicích, co se připojují k Jabberu by problém vyřešila hned.

Ale na to si ještě chvilku počkáme... zatím musíme prorážet NATový konfigurace a tvářit se, že je všechno v pořádku :).

IPv6 je hodně pěkná věc.

[mrzout]

Dalším nedostatkem pro odstranění ve frontě hned po VoIP je IMHO absence videokomunikace.

OK, s IM to nemá nic společného, ale to ani hlasová komunikace a běžný uživatel to nerozlišuje.

[Ilfirin]

Jingle bude podporovat i tu.

XEP-0166: Jingle

This document defines a framework for initiating and managing peer-to-peer multimedia sessions (e.g., voice and video chat) between two Jabber/XMPP endpoints in a way that is interoperable with existing Internet standards.

[mrzout]

Tak to je pro mne novinka a moc mě potěšila. Díky!

[zenek]

XEP-0180. Zárodky protokolu už jsou... Zárodky implementace už snad taky, tuším, že v telepathy s tím něco kutili.

Vývojářů je málo.

[Käyttäjä 11133]

Pokud je mi známo tak není problém nedostatek vývojářů, ale absence kompletního standardu.

[pavlix]

Kdyby byl dostatek vývojářů, asi by to urychlilo i opravování těch specifikací.

[StanV]

Vemte ješte v potaz Google Talk, který má hlasovou komunikaci již implementovanou. viz.Google Talk Open Communications.

[Ilfirin]

Dyť se o něm v článku mluví. Navíc článek pojednává o jabberu obecně aproto nemůže být hlas. komunikace v google talk (protože je to opět jen na google talk) brána v potaz. V GT není Jingle standard, jež se teprvé chystá (defacto je tam jeho Alfa, pokud vím).

[pavlix]

Google slíbil opravit svojí implementaci po vydání finálního standardu.

Takže to vypadá docela slibně.

[Michal Vojan]

Akorát včera jsem na tenhle protokol přešel, protože mi přišlo, že vývoj icq klienta, kterého jsem dost dlouho používal, jde pomalu k ledu. Sice mám teď v seznamu pouze jeden kontakt z třiceti jabberovský, na ostatní používám icq transport, ale snad to bude bez problémů, a třeba budou pomalu konvertovat i další. Možnosti, které XMPP nabízí, jsou určitě výhodou a hodně jeho rozšíření pomohou.

[pavlix]

Good for you :)

[priest]

naco jinle ked tu mame sip? nebolo by lepsie vytvorit len nejake riesenie ktore jingle spristupni cez xmmp?

[Ilfirin]

... vytvorit len nejake riesenie ktore jingle spristupni cez xmmp?

Asi jste chtěl říci SIP zpřístupní přes xmpp.
1.) SIP je omezen peeringem (moc moc moc moc vážný nedostatek), jabber není.
2.] Jingle má (možná pomocí rozšíření, to nevím přesně) toto umět. Stejně tak i na IAX.

[Ondrej 'SanTiago' Zajicek]

SIP neni omezen peeringem. To ze nekteri provozovatele SIP serveru blokuji spojeni z jinych nez z vybranych serveru, je uplne jina zalezitost - to mohou delat i provozovatele emailovych nebo jabberovych serveru.

[pavlix]

No z toho, co našel Ilfirin za zdroje to vypadalo, že se provozovatelé SIPu domlouvali na peeringu jednotlivě. Jeden měl dokonce na webu formulář k přidávání jiných sítí.

Takže možná se neliší protokol, v tomhle... ale asi se docela liší běžná praxe.

[zenek]

Jingle je rozšířením XMPP, které vyjednává multimediální spojení. SIPu nerozumím, ale jsem si jistý, že kluci z XSF vědí dobře, proč ho nepoužili. Asi kvůli XML. Pokud je mi známo, tak se ale při návrhu Jingle myslí na kompatibilitu se SIP...

[pavlix]

Jingle je SIP převedený do Jabberu.

Není problém překládat přímo mezi SIPem a Jingle.

Takže odpověď zní... nebylo by to lepší, protože to je přesně to, co se dělá.

(předpokládám, že tím druhým jingle byl myšlen SIP).

[mirec]

Nebola tu spomenuta taka drobnost - integracia jabberu do inkscape (inkboard). Vdaka tomuto rozisreniu je mozne po sieti kreslit inkscape <--> inkscape ;) Velmi zaujimava i ked nie moc pouzitelna somarinka :D

[pavlix]

No já si myslím, že bude hodně použitelná, aspoň až se vychytají mouchy. Chci to někdy vyzkoušet.

[Adrin]

Co mi u Jabberu chybí, je možnost dynamického přesunu účtu. Jabber skutečně funguje jako email - adresa je odvozená od jména serveru a účet je pevně svázán s tímto serverem. Ale já bych chtěl něco víc. Něco co mi dovolí migrovat po serverech bez nutnosti měnit jméno a vždy znovu vytvářet, nebo importovat seznam kontaktů. Vlasně takový Jabber postavený na protokolu digitálních identit.

On s tím souvisí i problém přeposílání zpráv (přesměrování z jednoho Jabber serveru na jiný - třeba když mi někdo píše na google, ale já už používám jabbim). Našel jsem i pár diskusí, kde se řešila možnost jabber2jabber transportu (ten by mimo jiné měl umět stáhnout seznam kontaktů z jiného serveru). Ale prý by tohle přineslo víc problémů než užitku...

Holt je internet stále server-středný a nikoli uživatelsky-středný. Zato je víc anonymní.

[Käyttäjä 11133]

Ona by úplně stačila možnost jako je u e-mailu... Nechat si doručené zprávy posílat na jiný účet. I v současné době má mnoho lidí více e-mailových účtů, z nichž si poštu přeposílá na jeden primární.

[pavlix]

Čistě technicky taková možnost je. Navíc mám dojem, že se na tom i nějak pracuje (nějaký XEP na tohle téma jsem zahlédl).

[pavlix]

Zajímavá myšlenka, ale to už je věc dost složitá. A myslím si, že kdyby to tak udělali, tak se o to spousta firem nebude vůbec zajímat.

[hwsoft]

To nechapu, o co se nebudou zajimat o jabber nebo o to preposilani?

[.]

jabber fakt doporucuji

[pavlix]

Tak tos mohl napsat něco víc :)

[thingie]

Hm. Tak třeba to že se nepoužívá potvrzení o přijetí zpráv mi nepřije úplně šťastné.

[pavlix]

Je to relativně nové rozšíření... co si pamatuju, tak debaty o tom, jak to bude vypadat byly dost divoké. Pak bylo rok úplné ticho a nakonec někdy na přelomu roku vyšla docela pěkná specifikace.

Až se vývojáři odhodlají to implementovat, tak to spolehlivosti docela dost pomůže.

Bylo dokonce pár lidí, kteří chtěli, aby zprávy byly potvrzováný (jenom) finálním příjemcem, což je nesmysl. Když je někdo offline, invisible, nebo vás neautorizoval, tak by to hlásilo chybu, i když se žádná nestala a zpráva byla buď uložena na serveru nebo doručena.

Škoda, že se to špatně hlídá na úrovni TCP, které mělo sloužit ke spolehlivému propojení.

Taky budu rád, až se to uvede do běžné praxe.