Tento článek má za cíl nastínit, jakými způsoby mohou dva objekty spolu komunikovat a jaké principy při tom platí.

Stejně jako lidi spolu navzájem mluví, komunikuje spolu i vše v počítači a na nejrůznějších úrovních. Procesor komunikuje s pamětí, operační systém s procesorem, program s operačním systémem či s jinými programy nebo různé moduly, objekty i funkce programu mezi sebou. Na to, jakými způsoby spolu mohou věci v počítači komunikovat, se podíváme v následujícím článku.

 

Klient a server

Komunikace má za cíl poskytnout nějaké informace druhé straně, případně si je vyměnit - komunikace tedy může být jednosměrná či obousměrná.
Ten, kdo informaci potřebuje (získat, předat, nebo vyměnit), a kdo tedy komunikaci zahajuje, se obecně nazývá klient. Ten, kdo informaci naopak nabízí, se nazývá server. Při komunikaci tedy dochází k nerovné situaci, kdy jedna strana informace potřebuje a druhá poskytuje.
Pojmem peer-to-peer se pak označuje situace, kdy jsou si dvě komunikující strany zdánlivě rovny. Při jejich komunikaci jde ale opět o sérii výměn informací, kdy jedna strana informaci potřebuje (získat, předat, obojí) a druhá ji poskytuje; pouze s tím rozdílem, že při tomto postavení se tyto role během komunikace běžně prohazují, a obě strany tak vystupují jak v roli klienta, tak serveru.

 

Co nás při komunikaci zajímá?

Toto rozlišování ale není pro programování dostatečné - vedle směru komunikace nás zajímá řada dalších věcí, které vědomě už příliš nevnímáme, přesto v jejich souvislostech i při běžném hovoru uvažujeme. Při psaní programů je ale nezbytné mít všechny tyto věci ujasněny.

Co chceme říct
Především musíme před samotnou komunikací vědět, co vlastně chceme říct. Pro běžný hovor dvou lidí to neznamená žádnou překážku, ale v programování tento aspekt hraje důležitou roli, protože jsme omezeni schopnostmi komunikujícího, kterým může být nějaký objekt, který zkrátka něco “neumí”, a neumí to tedy ani vyjádřit. Buď to za něj tedy musí vyjádřit někdo jiný (jiný objekt), nebo se to onen objekt musí nějak “naučit” - doprogramováním, dodáním nějakých dat apod.

Komu to chceme říct? Kdo je druhá strana?
Před zahájením komunikace také musíme vědět, komu chceme danou věc říct. Když Vás známý poprosí, abyste něco vyřídili Frantovi Urbanovi a Vy přitom žádného Frantu Urbana neznáte, budete muset nejdřív zjistit, který člověk to vlastně je. Přitom podstupujete riziko, že se za Frantu Urbana bude vydávat Pavel Sládek, nebo že sice narazíte opravdu na Frantu Urbana, ale na jiného, než kterého myslel Váš známý.
Ve světě počítačů to bývá ještě složitější. Například Váš internetový prohlížeč si před vstupem na jakékoliv stránky, které zadáte “slovně”, nejdřív zjišťuje, kdo je vlastně protistrana. U důležitých stránek (banky, úřady apod.) si navíc ještě ověřuje, že ona stránka je skutečně ta, za kterou se vydává, a to tak, že daná stránka předloží “občanku” stvrzenou (téměř) nezfalšovatelným podpisem autority, které obecně věříme (něco jako policejního příslušníka). A ani tak nemáme vyhráno (např. kvůli tzv. man in the middle problému).

Uslyší nás druhá strana? A poslouchá nás vůbec?
Zde jsou zmíněny hned tři problémy. Když si chceme s někým povídat, musí se naše komunikace k cíli být schopna nějak dostat, dotyčný nás musí slyšet (ve smyslu být schopen nás slyšet) a musí být připraven nás poslouchat. Musíme u něj tedy stát nebo mu třeba zavolat, vědět, že netrpí vadou sluchu, a ujistit se, že se nám věnuje.
Totéž samozřejmě platí v programování. Když posíláme některá data přes internet, nemůžeme si být ani jisti, že se k cíli vůbec dostanou - a přitom nemusí jít ani o přerušení spojení. I když se k cíli dostanou, druhá strana je jednoduše ignoruje a “nezabývá” se jimi (např. TCP pakety v tzv. broadcast režimu). A jindy data skutečně protistraně chodí, ale ta se zrovna věnuje něčemu jinému a nemá čas je zpracovávat.

Bude nám druhá strana rozumět?
Pokud víme, co a komu chceme říct a máme i zajištěnu dostatečnou schopnost i pozornost protistrany, musíme mít vyjasněno, zda nám protistrana vůbec bude rozumět. Když spustíme na běžného Čecha norsky, chápavý výraz od něj čekat nemůžeme.
Totéž platí v programování. Musíme si být jisti tím, že například při komunikaci po internetu rozumí druhá strana protokolu, který používáme.

Bude druhá strana vědět, o čem mluvíme?
Když budeme na české dítě mluvit sice česky, ale o politice a schodku rozpočtu, bude se dítě také tvářit nechápavě. Ne proto, že by případně už neznalo jednotlivá slova, ale proto, že nepochopí, co vlastně chceme říct.
Do jisté míry souvisí tento aspekt s předchozím uvedeným, protože v tom, co jsme schopni vyjádřit, jsme omezeni prostředkem, kterým to vyjadřujeme, v tomto případě tedy řeč omezuje vyjádření myšlení.
Přï programování si zase musíme být jisti, že druhá strana bude vědět, co má na základě sdělení vykonat apod.

Chceme vědět, zda nás druhá strana slyšela, rozuměla nám a věděla, o čem mluvíme?
Všechny tyto otázky jsou vlastně potvrzeními o správném provedení každé z výše uvedených věcí, které nás mohou zajímat. Abychom si mohli být jisti, že nás druhá strana slyší, že se k ní naše komunikace dostává a že jí rozumí, musí nám o tom druhá strana aktivně dávat vědět.
Například při psaní SMS lze jako parametr zprávy zvolit možnost doručenky. Nejde o nic jiného, než že mobil druhé strany po přijetí zprávy dá aktivně vědět (operátorovi a operátor nám), že zprávu přijal.
Taktéž ve světě počítačů se posílají potvrzení na všechno možné. U TCP protokolu nám dává protistrana například vědět, že je připravena s námi komunikovat (tzv. navázáním spojení) a že se k ní dostávají data (potvrzuje přijetí každého TCP paketu), spousta vyšších protokolů také to, že zprávu přijali, rozumí jí a že ji budou zpracovávat.

Zajímá nás odpověď?
Důležitou roli při komunikaci hraje, zda nás vůbec zajímá odpověď, nebo zda nám stačí vědět, že naši zprávu protistrana v pořádku přijala a zpracovala ji (nebo ani to ne).
Když povíme kamarádovi, že jsme byli včera na diskotéce, žádnou odpověď nečekáme. Když se ho zeptáme, kolik je hodin, čekáme, že nám poví čas.
Některé programovací jazyky mají pro komunikaci typu sdělení/příkaz dokonce jiný termín i použití (procedura) než pro komunikaci typu otázka (funkce), jinde toto rozlišuje pouze typ (prázdný/neprázdný) návratové hodnoty funkce.
U protokolů (jimž bude věnován jeden z příštích článků) navíc musí být oběma stranám předem jasné, na který dotaz se čeká odpověď a na který ne, jinak by komunikující strana mohla na odpověď čekat donekonečna.
Pro posílání odpovědi pak opět platí všechna shora uvedená pravidla.

 

Broadcast

Při běžné komunikaci mluvíme přímo s protistranou, buď jí něco vysvětlujeme a pak dostáváme potvrzení toho, že tomu druhá strana rozumí a chápe to, různým přikyvováním a slovy jako hm, aha, nebo se jí na něco ptáme a pak rovnou dostáváme odpovědi.
Pokud je ale způsob komunikace jednosměrný směrem od komunikujícího (neznáme protistranu a ta nám nemá jak dávat vědět odpovědi, zda komunikaci rozumí a ani zda ji vůbec dostala), nazýváme takovou komunikaci vysílání (broadcast). Navíc je taková komunikace zpravidla určena pro široké spektrum poslouchajících.
Je to opravdu totéž jako vysílání u televize. Vysílač pouze šíří televizní a případně rádiový signál, aniž by věděl, kolik a kteří příjemci jeho data zpracovávají. A ani ho to vlastně nezajímá. Pokud televizor nějaké vysílání “minul” třeba kvůli chvilkovému rušení, když si soused zapnul vrtačku, nelze si už zpětně vysílané informace vyžádat. Ani u teletextu není princip přirozeně jiný, vysílač dokola odesílá všechny stránky teletextu. Pokud si je všechny televizor není schopen zapamatovat, musí si počkat na další “kolo”.
Také větší naprogramované systémy často broadcastují, což spousta protokolů (např. PGM, ale i TCP) podporuje (v případě TCP už ho ale nepodporují běžná zařízení na internetu) samozřejmě i s jejich implementacemi. Vypadá to zhruba tak, že se vytvoří broadcastová skupina (s jednoznačným jménem), pro kterou nějaký poskytovatel dat vysílá informace. Kdokoliv se pak může do takové skupiny přihlásit a tato data přijímat. O doručování se pak stará jádro implementace daného protokolu.
Daleko častěji se však v programech broadcastuje proto, že program tak dává vědět změny různých svých dat, například typu “přibyla objednávka”, “změnila se objednávka”, “smazala se objednávka”. Kdokoliv, kdo je k takovému vysílání připojený, pak tato data dostává.

 

Pollování

Představme si, že potřebujeme od manželky zjistit, jestli je už připravena vyrazit s námi na zábavu. Přijdeme tedy za ní a přímo se zeptáme. Manželka nám odpoví, že ještě není připravena a poskytne nám případně také svůj podceněný zbývající čas přípravy.
Po pěti minutách nám to ale nedá a jdeme se zeptat znovu. Ani nyní ani v následujících dalších třech pokusech však nejsme úspěšní.
Teprve napošesté se s námi manželka vypraví a zábava může začít.
To, co jsme doposud prováděli, je princip pollování. Jde o opakovanou tutéž komunikaci až do splnění nějaké podmínky.
Je to jednoduchý princip postavený na přímé komunikaci, který má ovšem jednu zásadní nevýhodu, a to tu, že vyžaduje naši opakovanou aktivitu, abychom mohli zjistit nějaká data (například to, zda je manželka připravena vyrazit). Kromě toho, že nás to stojí úsilí a čas, který jsme mohli věnovat například sledování rozhodujících 5 minut fotbalu, se také připravujeme o čas, kdy manželka skutečně přípravu dokončila a než jsme se poté znovu zeptali.
Tutéž nevýhodu má pollování také v programování. Zde nás pollování stojí procesorový čas a výkon počítače. A samozřejmě poté, co je pollování úspěšné, jsme se už připravili o čas, kdy se požadovaná podmínka skutečně vyplnila.

 

Publish-subscribe

Můžeme totiž provést ještě jinou věc. Můžeme manželce říct, ať nám dá sama vědět, až bude připravena. My se mezitím můžeme v klidu dívat na fotbal. Jakmile nám manželka řekne, vypneme televizi a jdeme na zábavu.

Tento princip se nazývá publish-subscribe. V jeho rámci musí manželka vůbec nabízet schopnost dát nám vědět, že už skončila (to člověk splňuje automaticky, protože umí mluvit a zná význam dokončení, v programování se ale musí objekt k takové schopnosti nějak “přiznávat”). Pokud o této schopnosti víme, musíme se k této schopnosti nějak “přihlásit” (subscribnout), tedy vyjádřit, že máme zájem o to, aby nám manželka dala sama vědět. To jsme provedli tím, že jsme o tom manželce řekli. Subscribnutí samo o sobě je klasická přímá komunikace, kde nám publishující objekt dává vědět, že nás jako subscribnuté vůbec zaevidoval. Manželka si tuto naši žádost tedy musí zapamatovat. Poté, co přípravu dokončí, si manželka vzpomene, komu všemu měla dát vědět, a uvědomí nás (vyvolání události).

Výhoda takového přístupu je jasná, můžeme zatím dělat něco jiného a neztrácíme čas. Tento přístup má ale také nevýhody. Manželka na nás může jednoduše zapomenout a v těžším případě bez nás i odejít. Nebo se my po hodině čekání můžeme pustit do něčeho, co nás vytíží na další hodinu, v jejíž půlce manželka přípravu zrovna dokončí.
Pokud jsme se přihlásili k odběru novinek z nějakého serveru, nebude k nám tento server navíc tak hodný jako manželka, aby nás od odběru odhlásil (unsubscribnul) tehdy, když rozumně předpokládá, že danou službu už nebudeme potřebovat (manželka to udělala za nás). Místo toho nás bude zahlcovat novinkami, až dokud my sami nedáme vědět, že si je již dostávat nepřejeme.

Kromě toho se zpravidla k nabízené události může přihlásit víc lidí. Manželka tak může o dokončení přípravy dát vědět jak nám, tak své kamarádce na telefonu.

Navíc v modelu publish-subscribe figuruje ještě třetí entita, kterou jsme doposud nezmiňovali, a sice posluchač (listener). Jde o to, že tím, koho k odběru nějakých informací přihlašujeme, nemusíme být nutně my sami, ale můžeme přihlásit i někoho jiného. Jako by manželce řekl Franta, ať nám dá vědět, až bude připravena. Subscribnul nás Franta, který se o další události už nezajímá.

Kromě toho může dva komunikující subjekty “dát dohromady” ještě úplně jiný, třetí subjekt. Například na poptávkových serverech se jedna strana zaregistruje, že má zájem o nějakou službu, a druhá strana zase, že službu nabízí a má zájem o poptávky. Poptávkový server pak sám nabízejícího a poptávajícího spáruje a dá o protistraně každým z nich vědět.
Jindy za takové dva subjekty onen třetí subjekt dokonce komunikuje, takže jedna strana tu druhou vůbec nezná. Tak je to často například při obchodování na burzách. Když nakoupíte akcie, je vlastně jedno od koho, obchod zajišťuje i garantuje burza a clearingový dům.

V programování má model publish-subscribe nezastupitelnou roli. Běžně se používá u nejrůznějších zdrojů dat (např. evidence objednávek), které když změní jeden připojený klient, zdroj dat rozpošle tuto událost všem subscribnutým objektům (listenerům) a tyto si podle toho například obnoví data na obrazovce. Ostatní uživatelé se tak dozvědí, že někdo něco změnil (např. přibyla objednávka), aniž by museli celý seznam znovu načítat.
Publish-subscribe model je v mnoha programovacích jazycích přirozeně podporován pomocí tzv. událostí (events). Událost lze deklarovat (publishovat), vyvolat (fire), subscribnout se na ni a později se odsubscribovat a samozřejmě lze na vyvolanou událost něco provést (handle). Na jiných úrovních existují pro podporu publish-subscribe modelu nejrůznější frameworky, nově například Windows Communication Foundation v rámci .NET Frameworku.

WWW a publish-subscribe

Velkou nevýhodou dnešního pojetí webových stránek je právě neexistující dokonalá podpora pro publish-subscribe komunikaci v důsledku bezstavovosti serveru (o stavech bude pojednávat jeden z dalších článků), i když i v tomto ohledu se svět vyvíjí.
Když si představíme klasický chat, o co plynulejší komunikace by byla, kdyby nám sám dával chatový server vědět, že právě přibyl řádek s tímto textem (tak, jako je tomu například v případě IRC), a náš prohlížeč by si tento řádek připsal do okna, kde chat vypisuje. Místo toho musí prohlížeč pravidelně pollovat chatový server, aby se o změněných datech vůbec dozvěděl. Novější technologie jako AJAX sice umožňují načíst pouze část stránky a později překreslit pouze tuto část bez nepříjemného bliknutí celého okna, principiálně to však stále nelze ve všech případech (např. u všech prohlížečů) provést bez pollování a s využitím jediné technologie.

 

Závěrem

Komunikace hraje v programování nezastupitelnou roli a její principy a jejich výhody a nevýhody je nutné znát.
Existují také další, již poměrně složité modely komunikace (různé peer-to-peer síťové modely se strukturou uzlů a listů), ale ty jsou implementovány jen v několika málo obrovských systémech typu Facebook, Skype, Google apod. a beztak stavějí na elementárních principech popsaných zde. Při běžném programování si však plně vystačíme s pochopením principu pollování a publish-subscribe a jejich souvislostí.

Autor je technickým ředitelem společnosti RM Software.

Komentáře v diskuzi

Přidat komentář

Jméno (povinné)

E-mail, nebude zveřejněn (povinné)

Web

Ochrana proti spamu: (povinné)*
Opište prosím text z obrázku.