Dotaz: Implementace Jabber serveru

[faha]

Zdravim,

pracuji na uzavrenem projektu, kde si nekolik ruznych casti celeho systemu, ktere bezi na fyzciky oddelenych zarizenich a komunikuji skrze LAN, musi vymenovat kratke textove informace.

Napadlo me pouzit k vymene techto informace jako transportni kanal interni jabber server (jednu z vyhod vidim rychlost, transparentni moznost sifrovani, otevrene reseni, dostupnost implementace jabber klienta pro velkou skalu jazyku a budouci moznost jednoducheho rozsireni pristupnosti pro mobilni platformy), v pripade potreby ho obohatit o nejake perl bota, ktery dokaze zaridit nektere udalosti.

Otazkou zustava zda-li nema tento navrh nejake fatalni uskali, ktere momentalne nevidim, pustim se samozdrejme do referencni implementace, na ktere se pokusim demonstrovat moznosti systemu ostatnim vyvojarum, ale presto lecos mi mohlo uniknout, sazim, ze testovaci implementace toto dokaze brzy odhalit.

Jedna z klicovych otazek je jaky jabber server nasadit?

- ejabber (Erlang - nemam zadne zkusenosti, zrejme implementace pro vytizene servery, "kanon na vrabce"?)

- jabberd ( vypada zajimave, otazka jakou verzi 1.4 x 2.0 )

- openfire a jine implementace  v jave ( nelze, java neni dostupna na cilovem system )

- prosody (celkem zajimava implementace v jazyce Lua, ktery trochu ovladam, bojim se o stabilitu)

- jiny? (tibase? apache vyper? )

Jabber server by mel byt schopen bezet i na rekneme relativne slabem HW ci mit moznost ho kompilovat i pro jinou architektu nez je x86.

Jabber server nebude verejny, tedy neumozni registraci, presto bych chtel mit moznosti nejakym zpusovat spravovat uzivatele (at uz jsou napr. v obycenem souboru ci db), nepotrebuji podporu pro transporty, hodila by se mi moznost specifikovat v samotnem jabber omezeni komunikace (tedy ze klient xyz muze komunikovat jen abc klientem), zda-li je to mozne, potrebuji v takovem pripade napr. roster module?

Otazek je pomerne mnoho, nechavam prostor pro komentare ... diky za vas nazor. F.

Odpovědi

[Messa]

Co třeba RabbitMQ a podobné? V podstatě chcete messaging nebo message bus nebo tak něco, což se celkem běžně používá, ale ne nad Jabberem :)

[faha]

Diky, to vypada zajimave a koukam, ze take napsane v Erlangu.

Seznam dalsich MQ

http://en.wikipedia.org/wiki/Message_broker

[Sten]

Pro messaging různých komponent bych preferoval jiné technologie:

• IRC: jednoduchý protokol, dodnes číslo jedna pro takové systémy, omezení komunikace mezi uživateli jsem tam ale neviděl
• D-Bus: klasický linuxový message server, umí pracovat i přes síť, detailní (ale složité) nastavení oprávnění
• Avahi: zeroconf technologie, decentralizované, používá multicast a broadcast, složité zprovoznění na více logických sítích, práva musí hlídat příjemce zpráv

Jinak co se týče Jabberu, tak jabberd bych nebral (rozhodně ne 1.4), strašně to leakuje, špatně se to konfiguruje, 1.4 neumí IPv6, je to pomalé a vůbec je to takový moloch spíše na testování XMPP než reálné nasazení.

ejabberd je hodně dobrý (rychlý, paměťově nenáročný), dá se snadno rozšiřovat nebo i clusterovat, ale psát něco v Erlangu pro mě bylo utrpení.

Pokud máte rád Perl, tak by se vám mohl líbil DJabberd

Ještě je zajímavý Psyced, umí totiž komunikovat mnoha různými protokoly a mezi nimi překládat a snadno se clusteruje.

[faha]

Diky za reakci

- IRC me napadlo na zacatku jako prvni, ale zavrnul jsem to a zacal uvazovat spise o necem s XMPP

- D-Bus znam ale z nejakeho duvodu mi to neprijde sympaticke

- Avahi neznam, ale podivam se

Procetl jsem letmo dokumentace k ejabberd a taky feature list a nusim uznat, ze to co tam pisou je jak balada a moc dobre se to posloucha co vsechno to umi (Cross-platform, Distributed, Fault-tolerant ... holt s tim Erlangem vsadili na dobreho kone)

A taky jsem objevil toto http://www.zeromq.org a libi se mi to moc, tak musi premyslet, zda-li smysl o tomto uvazovat nebo zkusit reseni s tim ejabberd.

[Josef Kufner]

Od jaberd jsem přešel k ejabberd a jsem celkem spokojen. Být tebou, tak vemu ejabberd a neřeším to – je celkem nenáročný a spolehlivý.

Co se protokolu týče, XMPP je dost pěkné, jednoduché a hlavně rozšiřitelné na to, aby se to dalo lehce použít. Taky tam je RPC a podobné věci, které by se mohly hodit. Zvážil bych využití MUC (hlášení chyb a jednoduchý přehled všech online serverů i pro více lidí).

IRC nebrat, brzy narazíš a navíc je už deprecated (dá-li se to tak říct – koukni na silc, ale stejnak v tom vedle XMPP moc nevidím budoucnost). Jednoduchostí protokolu si s IRC nijak nepomůžeš, protože u XMPP ti stačí jen poslouchat výstup xml parseru a knihovny na to už existují.

[Sten]

Na druhou stranu parsování XML je poměrně náročné na výkon a paměť, proto se na vysoce zatížené spoje používají alternativy.

Btw. já preferuji SCGI, protože je to extrémně rychlé a snadno se dá použít s HTTP proxy, ale není to centralizované, musel by si napsat i nějaký SCGI hub.

[faha]

Jak moc narocne je parsovani XML? Dokazal by jste to specifikovat pripadne rozvect ty mozne alternativy? Diky F.

[Sten]

XML parsování (pokud se má dělat dobře) je náročné hlavně kvůli ukecanosti XML. Je potřeba ukládat si jména tagů, aby se mohly kontrolovat vůči zavíracím tagům. Také je dost obtížné rozpoznat, co je nezajímavý bílý znak (třeba odsazení) a co text, který aplikaci zajímá (nejsou syntakticky nijak oddělené), proto parser musí předávat aplikaci i bílé znaky, i když by je mohl zahazovat. Stejně tak escapování je dost složité na zpracování, protože entity mohou být nadefinované v DTD. Validace vůči DTD je také hodně náročná. A jak se má parser zachovat, když to bude rozbité? Celé XML je velmi robustní, ale také velmi náročné na zpracování podle specifikace. Hodí se IMHO na data, když potřebujete zajistit spolehlivost přenosu mezi heterogenními prostředími a rychlost není důležitá.

Jako alternativy mohou být třeba JSON (resp. JSON-RPC), D-Bus, seznamovské FastRPC, Google Protobuffers, ZeroC Ice nebo EBML (používá Matroska).