TIPC byl vyvinut původně ve společnosti Ericsson pro použití v telekomunikačních aplikacích. Nyní je uvolněn a vyvíjen pod GPL licencí. Na vývoji se nadále podílí zejména společnosti Ericsson, WindRiver. Motivací při návrhu protokolu bylo zajistit prostředky pro transparentní komunikaci nodů v rámci clusteru. Dalšími požadavky byla spolehlivost komunikace a efektivita.
Předpoklady, ze kterých se vycházelo při návrhu protokolu, byly: komunikace na krátkou vzdálenost – tím se rozumí bez hopu, kdy dva uzly spolu budou typicky komunikovat přímo bez prostřednictví routeru apd. – a použití krátkých zpráv, požadavek na vysokou spolehlivost spojení a další.
V linuxu je implementace TIPC přítomna od verze 2.6.16.
K čemu slouží?
Jak bylo řečeno, TIPC byl vyvinut pro nasazení v telekomunikačních aplikacích. Současné telefonní ústředny totiž čím dál tím více používají pro vnitřní komunikaci paketové sítě (mluvíme o ústřednách pro klasické telefony, ne VoIP apod.). Současná telefonní ústředna je komplexní systém sestávající z mnoha modulů, které se starají mimo jiné o přenos signalizace (protokol/informace, podle kterých se sestavuje a řídí hovor), vlastní přenos hlasu, ale i další doplňkové služby. Odhlédneme-li od přenosu hlasu, jsou přenášené informace často relativně malé, ale je nesmírně důležité, aby jejich doručování bylo spolehlivé, rychlé a do jisté míry pravidelné. Nejmarkantnější je situace zřejmě u signalizace, kdy např. při použití signalizačního protokolu SS7 je efektivní délka přenášených dat nejčastěji mezi 3 až 5 B. Účelem těchto zpráv je detekovat stav spojení mezi dvěma komunikujícími stanicemi, jsou tedy nesmírně důležité pro vlastní funkčnost systému (nepracuje-li signalizace, netelefonuje se). Tyto zprávy se ale periodicky opakují s intervaly v řádech nejvýše desítek milisekund. Při požadavku na současné propojení tisíce a více linek se již jedná a velké nároky na kvalitu použitého řešení (pro představu obvyklý požadavek je na spolehlivost systému jako celku na 99.999%). Tolik k úvodnímu seznámení s prostředím, ve kterém se budeme pohybovat.
Proč ne TCP, SCTP?
K předchozí představě o použitém systému zbývá dodat, že typicky jsou použité moduly redundantní a jejich zapojení v systému (clusteru) se dynamicky mění během času. Nechceme-li tyto dynamicky se měnící konfigurace a z toho plynoucí změny ve spojení mezi moduly řešit na aplikační úrovni, je nutné využít prostředky (služby operačního systému, síťové protokoly, …), které tuto práci udělají za nás (např. zajistí pro aplikaci lokační transparentnost – nerozlišitelnost, zda komunikuje s procesem na lokálním nebo vzdáleném modulu -v terminologii clusteru označován jako nod-, popř. na kterém vzdáleném modulu se proces nachází) a tím zbaví danou aplikaci nutnosti starat se o technické detaily komunikace s konkrétním typem modulu (např. udržování synchronních informací u redundantních modulů, transparentní přesměrování provozu při selhání modulu, apod.). Tato a další specifika jsou příčinou toho, že protokoly, jako je např. TCP, nejsou zcela efektivní.
Pro TCP hovoří jeho velké rozšíření a všeobecně dobré povědomí o jeho vlastnostech. Nicméně pro nasazení v rámci clusteru se nejeví jako vhodný. Zejména proto, že nepodporuje nativní multicast (z principu – jedná se o protokol s tzv. spojovanou komunikací). Dále je při použití TCP nutné rozlišovat komunikaci „opouštějící“ nod a probíhající v rámci nodu. Existují sice různé nadstavby – jako například CORBA -, ty ale zavádějí další režii, která dále poznamenává efektivitu a rychlost komunikace. V případě TCP je navic samotné navázání spojení spojeno s velkou režií. Ve výše popsaném telekomunikačním prostředí pak toto je významným zpomalujícím prvkem, jelikož díky dynamicky se měnícím konfiguracím a z principu práce systému (v tomto případě telefonní ústředna) budou spojení navazována často. Navíc je TCP nejméně efektivní právě pro přenos relativně krátkých zpráv, které jsou do jisté míry pro dané prostředí typické.
SCTP je chápáno jako vhodnější protokol než TCP, nicméně některé z popsaných nevýhod se stále vyskytují.
Obecně je možné říci, že protokoly TCP, SCTP jsou nevhodné kvůli tomu, že se jedná o tzv. obecně použitelné protokoly, které se snaží řešit všechny potenciální problémy. Oproti tomu TIPC je úzce specializovaným protokolem, díky čemuž dosahuje na krátkých zprávách (< 1.5 kB) o 35–80 % lepší výkon než TCP/IP. Na větších zprávách je výkon srovnatelný, při větších zprávách (> 4kB) již je TCP výkonější.
Charakteristika TIPC
Doposud byly zmíněny pouze úvahy a motivace vedoucí k návrhu protokolu TIPC. Zde jsou uvedeny jeho vlastnosti, které bývají nejčastěji zmiňovány. Protokol TIPC podporuje:
- Spolehlivé a nespolehlivé nespojované komunikační mody (SOCK_RDM a SOCK_DGRAM).
- Spolehlivé na spojení orientované komunikační mody (SOCK_SEQPACKET a SOCK_STREAM).
- Spolehlivé a nespolehlivé všesměrové vysílání přes celý cluster.
- Funkční adresovací schéma, jež umožňuje adresování přes primární/sekundární klíč a skupinové adresování.
- Možnost adaptace na různá média a protokoly v závislosti na síťové infrastruktuře a bezpečnostních požadavcích: Ethernet, RapidIO, ATM/AAL5, TCP, SCTP, UDP atd. Typicky se ale předpokládá nasazení nad protokoly Levelu 2.
- Topologická služba pomáhající aplikacím znát funkční a fyzické adresy v clusteru.
- Provoz TIPC je předpokládán v rámci zabezpečené sítě, proto TIPC neobsahuje žádnou podporu pro zabezpečení přenášených dat.
- Rychlá detekce selhání linky (spojení mezi nody).
Shrnutí
Protokol TIPC byl navržen pro spolehlivou komunikaci v rámci clusteru. Zde byl diskutován v souvislosti s oblastí telekomunikací, pro kterou byl původně navržen. Jeho vlastnosti ale nabízí jistě daleko širší uplatnění. Mezi klíčové vlastnosti patří plná lokační transparentnost v rámci clusteru, podpora spolehlivého spojení, atd.
Na závěr teoretického povídání nezbývá než přidat odkaz na poněkud konkrétnější výsledky. Zajímavé srovnání výkonnosti TIPC a TCP na různých datech je možné nalézt na adrese www.strlen.de/tipc. V pokračování už bude naznačeno trochu více o architektuře a principech tohoto protokolu.
ČLÁNKY DO MAILU