Interoperabilita
Část 5.: Ovladače síťových karet - nositelé vzájemné spolupráce
V předcházejícím dílu této volné série článků jsme se zabývali problematikou rámců linkové vrstvy v sítích typu Ethernet, a způsobem vkládání síťových paketů do těchto rámců. Dnes se zaměříme na zajímavé implementační aspekty této problematiky - na ovladače síťových karet a jejich možné koncepce.
Požadavek nezávislosti zákazníka na konkrétním dodavateli, který je jedním ze základních pilířů všech otevřených (open) řešení, je v současné době snad nejvíce naplněn v oblasti nabídky osobních počítačů PC. Chcete-li si takový počítač koupit, můžete si vybírat z nabídek mnoha a mnoha výrobců, a rozhodovat se podle ceny, dodacích a záručních podmínek, celkového renomé výrobce resp. prodejce apod. Přitom máte rozumnou záruku, že vámi zvolený počítač bude odpovídat standardu počítačů PC - že na něm bude možné provozovat všechny běžné programy pro osobní počítače, a také že si k němu budete moci přikupovat nejrůznější hardwarové doplňky od kteréhokoli výrobce.
Pokud budete chtít zapojit svůj osobní počítač standardu IBM PC do lokální počítačové sítě (například do sítě typu Ethernet), budete si muset přikoupit ještě nezbytný síťový hardware, ve formě tzv. síťové karty. Dnešní počítače PC jsou do značné míry modulární, a lze je snadno rozšiřovat pomocí karet či desek, které se instalují do volných zásuvných pozic (neboli tzv. slotů) na matiční desce (tzv. motherboardu). To je zřejmě hlavní důvod, proč ještě i dnes, v době všeobecného nástupu lokálních sítí, není potřebný síťový hardware standardní součástí počítačů PC, ale pouze volitelným doplňkem, řešeným nejčastěji právě formou síťové karty.
Nabídka síťových karet pro počítače PC je dnes také velmi bohatá, a pokrývá značně široké spektrum - od nejlacinějších "bezejmenných" (no-name) karet až po nejdražší značkové karty od renomovaných výrobců. Jednotlivé karty se přitom mohou dosti výrazně lišit, pokud jde o jejich schopnosti i konkrétní způsob ovládání.
Podobně je tomu i s nabídkou nejrůznějšího síťového softwaru - také zde se potenciálním zákazníkům nabízí velký výběr síťových operačních systémů, síťových utilit a mnoha dalších programů.
V tuto chvíli se ale neodbytně vnucuje zcela zásadní otázka: "je možné libovolně kombinovat síťové karty a síťový software"? Nebo jinak: "mohu se spolehnout, že ten síťový software, pro který se rozhodnu, dokáže spolupracovat s kteroukoli síťovou kartou, kterou si ke svému počítači koupím (nebo kterou již ve svém počítači mám)"?
Pokročilejší uživatelé si pak k této základní otázce jistě přidají i následující dilema: "budu-li provozovat souběžně více úloh, které pracují se sítí, dokáží se o jedinou síťovou kartu rozumně podělit"?
Každý s každým?
Vžijme se nejprve do role toho, kdo vyvíjí síťový software (obecně jakýkoli software, který pracuje se síťovou kartou): v době, kdy na svém programu pracuje, existuje na trhu určitá nabídka síťových karet. Autor nového síťového softwaru v zásadě může pamatovat na každou z nich, a svůj program uzpůsobit odlišným schopnostem a způsobům ovládání všech těchto karet (například formou různých verzí pro jednotlivé karty apod.). Co ale z principu nemůže, je anticipovat vlastnosti a způsoby ovládání takových síťových karet, se kterými výrobci přijdou až někdy v budoucnu. Tím ovšem použití všech těchto karet v podstatě vylučuje.
Cesta vzájemného přizpůsobení všech možných programů všem možným síťovým kartám tedy není schůdná již z principu. O její efektivnosti ani nemluvě.
Možnou alternativou by bylo omezit se jen na podporu menšího okruhu síťových karet od "renomovaných" výrobců, a požadovat od nich zpětnou kompatibilitu nově vyvíjených karet s již existujícími. To je ale značně diskriminující vůči ostatním výrobcům, kteří by nesměli přicházet s vlastním řešením, ale museli by se přizpůsobovat několika málo "vyvoleným" řešením.
Až na holé železo?
Představa, že tvůrce síťového softwaru se musí přizpůsobit konkrétní síťové kartě, mlčky předpokládá jeden velmi důležitý moment: že totiž příslušný software si síťovou kartu bude "obsluhovat" zcela sám. Jinými slovy: síťový software bude přímo pracovat s těmi ovládacími prvky, které síťová karta má - s jejími řídícími, datovými a stavovými registry apod.
To je na jedné straně velmi výhodné, protože při takovémto přístupu "až na holé železo" může síťový software maximálně využít všech schopností konkrétní síťové karty. Na druhé straně je ovšem nutné mít na paměti, že způsob ovládání na úrovni "holého železa" je pro každou síťovou kartu obecně jiný. Důsledkem je pak nemožnost přizpůsobení stylem "každý s každým", citovaná v předchozím odstavci.
Kromě toho je ale třeba si uvědomit také to, že síťové karty nejsou zdaleka jediným druhem hardwaru, který dnešním počítačům zajišťuje přístup do počítačových sítí. Jsou pouze jeho převažující formou, používanou pro připojování personálních počítačů standardu IBM PC do lokálních sítí, zatímco např. v rozlehlých sítích se jednotlivé uzlové počítače propojují pomocí pevných (ev. i komutovaných) telefonních okruhů, radiových či družicových spojů apod., a tyto přenosové cesty se nejčastěji připojují přes vhodné přizpůsobovací prvky (zejména modemy) na sériová rozhraní počítačů. Tím ale není repertoár možných způsobů připojení na síť ještě zdaleka vyčerpán - například přenosné počítače s oblibou využívají ke svému zapojování do sítí adaptéry, připojované k jejich paralelnímu rozhraní (paralelnímu portu). Jiné druhy počítačů zase mají ekvivalent síťové karty již zaintegrován na své systémové desce, nebo vyžadují použití síťových karet specifického druhu apod.
Ovladače musí psát výrobci hardwaru!
Představa přístupu "až na holé železo" tedy není pro tvůrce síťového softwaru dost dobře schůdná. V podstatě jedinou její rozumnou alternativou je oddálit síťový software aplikačního či systémového charakteru od "holého železa", a vložit mezi něj a konkrétní síťový hardware vhodný ovladač (driver), který zakryje jeho specifika (a který napíše výrobce síťového hardwaru!!). Toto řešení ovšem předpokládá stanovení vhodných konvencí, které dodrží jak tvůrce ovladače, tak i tvůrce síťového softwaru. Ve své podstatě tedy jde o vytvoření přesného rozhraní, jehož definici budou obě strany respektovat.
No a právě v definici tohoto rozhraní je skryt další zdroj problémů: kdo má příslušná pravidla a konvence stanovit?
Může to samozřejmě být i výrobce síťového hardwaru, ale v praxi takováto rozhraní stanovují téměř výlučně tvůrci síťových programů. Ti přitom mohou navrhnout příslušné rozhraní tak, aby vycházelo vstříc potřebám jedné konkrétní síťové aplikace či jednoho konkrétního systémového programu, který se sítí pracuje (např. síťového operačního systému), a výrobci síťových karet (či jiného síťového hardwaru) pak mohou ke svým produktům přidávat ovladače pro jednotlivé konkrétní aplikace. Tato strategie však znovu naráží na problém, který jsme již několikrát citovali: výrobce síťové karty nemůže anticipovat potřeby aplikací, které budou vytvořeny teprve v budoucnu. Potřebné ovladače pro ně sice může napsat až dodatečně, ale jejich následná distribuce jednotlivým zákazníkům nebude nikdy bezproblémová (ani zcela zadarmo).
Univerzální rozhraní k síťovému hardwaru
Proto se nelze příliš divit, že se velmi brzy objevilo volání po takových rozhraních, která by byla natolik univerzální, aby vycházela vstříc potřebám různých síťových aplikací a systémových programů, byla plně zveřejněná, a neposlední řadě byla všeobecně respektovaná.
Ve světě plném institucí, zabývajících se tvorbou a vydáváním všelijakých standardů a norem, by bylo možné očekávat, že standard pro příslušné rozhraní vznikne právě touto cestou. Pravý opak je ale pravdou: všechna dnes používaná rozhraní pro přístup k síťovému hardwaru vznikla jako vlastní (tzv. proprietární) řešení softwarových firem, a teprve časem se z nich staly všeobecně uznávané standardy. V tomto článku se podrobněji zastavíme u třech z nich, které jsou v dnešní době nejrozšířenější:
- rozhraní tzv. paketových ovladačů (packet drivers),
- rozhraní tzv. NDIS ovladačů (NDIS drivers).
- rozhraní tzv. ODI ovladačů (ODI drivers),
Sdílení síťových adaptérů
Další zajímavý problém vyvstává v okamžiku, kdy na svém uzlovém počítači potřebujeme souběžně provozovat několik úloh, které chtějí pracovat se sítí. Například na pracovní stanici pod MS DOSem si budeme chtít nainstalovat vše potřebné pro plně transparentní přístup k souborům na Novellském file serveru (tedy síťový protokol IPX a tzv. uživatelský shell systému NetWare), a současně s tím si budeme chtít spustit nějakou síťovou aplikaci - například takovou, která nám zpřístupní službu telnet pro vzdálené přihlašování k Unixovským počítačům (a která používá přenosové protokoly rodiny TCP/IP). K tomu ale bude nutné, aby vedle sebe existovaly implementace dvou různých sestav přenosových protokolů - tedy toho, čemu se v angličtině říká protocol stacks (doslova: zásobníků protokolů). V našem konkrétním případě by jednou takovouto sestavou protokolů byla implementace Novellských protokolů IPX/SPX, a druhou implementace Unixovských protokolů TCP/IP. V obecném případě ale může jít o vzájemnou koexistenci nejrůznějších sestav protokolů (protocol stacks) stejného i nestejného druhu - například více "instancí" protokolů TCP/IP, které si vytváří jednotlivé aplikace.
Výše avizovaný problém pak nastává v okamžiku, kdy jeden a tentýž síťový hardware (jednu síťovou kartu) potřebuje sdílet více takovýchto sestav protokolů. Pokud by každá z nich "sahala" až přímo na síťovou kartu, a chovala se přitom tak, jako kdyby byla na počítači sama, skončilo by to zcela jistě naprostým fiaskem.
Jakmile ale dojde k "oddálení" jednotlivých sestav protokolů od síťového hardwaru a pod ně se vloží vhodný ovladač, je možné tento ovladač uzpůsobit tak, aby dokázal spolupracovat s více sestavami protokolů, a rozděloval mezi ně veškerá přijímaná data.
Všechny námi zvolené druhy ovladačů tuto schopnost mají, ale každý z nich ji implementuje poněkud odlišným způsobem, ze kterého pak vyplývají i některé zajímavé důsledky.
Rozhraní paketových ovladačů
Historicky nejstarším je rozhraní tzv. paketových ovladačů (packet drivers), které pochází od firmy FTP Software, Inc., a je zřejmě nejvíce rozšířené mezi uživateli v akademických kruzích.
Zajímavá je i samotná historie vzniku tohoto rozhraní: jednou z úplně prvních implementací protokolů TCP/IP pro počítače IBM PC byl úspěšný výzkumný projekt profesora Jerry Saltzera na známé Massachussets Institute of Technology, jehož výstupem byla i soustava programů, nazvaných PC-IP. Tyto programy, implementující většinu standardních aplikací TCP/IP, byly v roce 1985 uvolněny (jako to volně šiřitelné programy, tzv. freeware), a staly se základem, na který záhy navázala řada dalších výzkumných projektů i čistě komerčních aktivit.
Jednou z nich bylo i založení firmy FTP Software, Inc. (v lednu 1986), která si předsevzala pokračovat ve vývoji PC-IP na komerční bázi, a uplatnit přitom některé další myšlenky, které v rámci projektu MIT již nebyly realizovány. Výsledkem byl kvalitní a dodnes velmi úspěšný komerční produkt PC/TCP, jehož první verze se dostala na trh v dubnu 1986. Jednou z osobností, které u firmy FTP Software uplatnily své myšlenky, byl John Romkey (který se ještě jako student významnou měrou podílel na realizaci původního PC-IP na MIT). Takovouto myšlenkou bylo i vytvoření standardizovaných ovladačů síťového hardwaru, které John Romkey nazval paketovými ovladači (packet drivers), a které firma FTP Software začala ve svých produktech používat. Specifikace příslušného rozhraní (tj. rozhraní mezi paketovými ovladači a sestavami protokolů vyšších vrstev) vznikla na přelomu let 1986 a 1987, a byla záhy plně zveřejněna - aby se jí výrobci mohli přizpůsobit, a ke svým síťovým kartám psát nezbytné paketové ovladače.
Výrobcům ovšem chvíli trvalo, než paketovým ovladačům "přišli na chuť". Mnohem dříve si je oblíbili uživatelé z akademických kruhů, kteří začali psát paketové ovladače pro nejrůznější již existující síťové karty. Vzhledem k obvyklé praxi na univerzitách v USA se tyto ovladače staly volně šiřitelnými, a to dokonce i ve zdrojovém tvaru. Úlohu hlavního koordinátora přitom na sebe vzala jedna z univerzit v USA, Clarkson University ve městě Potsdam ve státě New York, u které se nejrůznější paketové ovladače postupně shromažďovaly, až jich zde vznikla velmi bohatá a dobře udržovaná zásoba. Proto se také o paketových ovladačích někdy hovoří jako o "Clarkson packet drivers", a o jejich sbírce jako o tzv. "Clarkson packet driver collection". Ta se samozřejmě stala také hlavním referenčním zdrojem pro volné šíření všech paketových ovladačů.
V současné době ale již nemá Clarkson University s udržováním a šířením této sbírky nic společného. Stále se o ni sice stará stejný člověk, jako na univerzitě (pan Russell Nelson), ale nyní již v rámci firmy Crynwr Software. Proto se také příslušná sbírka paketových ovladačů nyní označuje jako "Crynwr packet driver collection".
Paketové ovladače byly a stále jsou volně šiřitelné programy (tzv. freeware). Lze je tedy získat buď zcela zdarma (například prostřednictvím sítě Internet), nebo i běžnou listovní poštou za malý manipulační poplatek (pokrývající cenu poštovného, magnetického nosiče atd.). Formálně tedy nejde o produkt, ke kterému by byly poskytovány další podpůrné služby, obvyklé u komerčních produktů - především pak tzv. uživatelský support, spočívající především v technickém poradenství, odstraňování chyb, vývoji nových verzí atd. V praxi je ale sbírka paketových driverů dobře udržovaná na nezávazné a neformální bázi, a případné chyby jsou v nových verzích odstraňovány (v listopadu 1993 se objevila již 11. verze sbírky paketových ovladačů - Crynwr packet driver collection, Release 11.x)
Postoj výrobců síťového hardwaru k paketovým ovladačům není jednotný. Většina z nich sice píše ke svým produktům i nezbytné paketové ovladače, ale existují i takoví výrobci, kteří tak nečiní (nejspíše kvůli svému nepříliš kladnému postoji vůči volně šiřitelným programům bez uživatelského supportu). Na druhé straně tvůrci nejrůznějšího síťového softwaru s paketovými ovladači vesměs počítají, a své produkty vybavují schopností pracovat s tímto druhem ovladačů. Existují dokonce takové produkty, které s ničím jiným než s paketovými ovladači nepočítají. Jsou to především nejrůznější volně šiřitelné programy, pocházející z akademického prostředí.
Jak funguje paketový ovladač
Paketový ovladač je nejlépe si představit jako program, který funguje na úrovni linkové vrstvy referenčního modelu ISO/OSI. Na této úrovni pracuje s tzv. rámci (anglicky: frames) - při příjmu dostává tyto rámce od síťové karty, "vybaluje" síťové pakety, které jsou v nich obsaženy, určuje jejich typ, a podle něj pak tyto pakety dále předává tomu, kdo má být jejich skutečným příjemcem (některé sestavě protokolů).
 |
Paketový ovladač je vždy jediným programem, který pracuje s danou síťovou kartou. Zde je tedy situace vcelku jednoduchá - síťová karta předává veškerá přijatá data právě a pouze "svému" paketovému ovladači (při současné existenci více síťových karet v jednom počítači má každá z nich nainstalován svůj vlastní paketový ovladač). Způsob, jakým paketový ovladač komunikuje se síťovou kartou, tedy neskýtá žádné principiální problémy. Je samozřejmě specifický pro daný síťový hardware (kartu), ale to je podstatné (a hlavně "viditelné") pouze pro toho, kdo paketový ovladač píše, a nikoli pro toho, kdo jej používá.
Zajímavější je spíše způsob komunikace paketového ovladače směrem "nahoru" - tedy směrem k sestavám protokolů, které implementují přenosové protokoly vyšších vrstev (síťovou vrstvou počínaje). Tento způsob komunikace je vždy jednotný, a je dán právě specifikací rozhraní k paketovému ovladači, vytvořenou firmou FTP Software.
Veškerá komunikace, iniciovaná protokoly vyšších vrstev, má formu programového přerušení - jeho konkrétní číslo (od 60H do 7FH) se pro každý paketový ovladač stanovuje v okamžiku jeho instalace. Paketový ovladač touto cestou (tj. prostřednictvím přerušení) nabízí předem stanovený repertoár služeb, popsaných v definici rozhraní k paketovým ovladačům - například služeb pro odesílání jednotlivých datových paketů.
Zajímavý je i způsob komunikace mezi paketovým ovladačem a protokoly vyšších vrstev v případě příjmu dat, kdy iniciátorem nutně musí být paketový ovladač. Zde platí obecné pravidlo, že protokol vyšší vrstvy, který chce od paketového ovladače jakákoli data přijímat, se u něj musí nejprve přihlásit. Jako součást své "přihlášky" přitom musí zadat i vstupní bod do své rutiny, která má být při příjmu volána. Když potom paketový ovladač nějaký datový paket skutečně přijme, předá jej jeho skutečnému adresátovi tak, že zavolá tuto jím určenou rutinu. Pravidla rozhraní k paketovému ovladači dokonce určují, že tak činí dvakrát: poprvé volá příslušnou rutinu proto, aby tato zajistila vytvoření dostatečně velké vyrovnávací paměti (bufferu) pro příjem paketu. Paketový ovladač poté sám zkopíruje datový paket do této vyrovnávací paměti, a druhým voláním příslušné rutiny o tom informuje příslušný síťový protokol.
Různé třídy paketových ovladačů
Zajímavé je na paketových ovladačích také to, že se nesnaží před vyššími vrstvami skrývat, s jakou přenosoovu cestou pracují (že jde například o sériovou linku, síť Ethernet, síť Token Ring atd.). Tyto se totiž liší v mnoha významných aspektech - například v přesném formátu rámců, způsobu převodu síťových adres na linkové, maximálním rozsahu přenášených bloků dat, přenosovém zpoždění atd. Standard paketových ovladačů počítá s tím, že tyto odlišnosti budou pro protokoly vyšších vrstev (zejména pak pro síťovou vrstvu) viditelné, a tyto vyšší vrstvy s nimi budou počítat. Z tohoto důvodu pak také existuje více různých tříd paketových ovladačů (viz tabulka 1), které se ještě dále dělí na různé typy (podle konkrétní síťové karty).
Alternativou k tomuto přístupu paketových ovladačů by bylo úplné zakrývání veškerých specifik používaných přenosových cest před vyššími vrstvami (tuto strategii aplikují tzv. ODI ovladače, viz dále).
Sdílení paketového ovladače
Paketové ovladače od začátku počítají s tím, že mohou být současně sdíleny více instancemi protokolů vyšších vrstev (sestavami protokolů, protocol stacks), a jsou tudíž vybaveny schopností demultiplexu (rozdělování) paketů mezi více potenciálních příjemců. Každý z nich je ovšem povinen se u paketového ovladače nejprve přihlásit, a přitom musí přesně definovat jaký druh paketů chce přijímat (přesněji: musí paketovému ovladači sdělit, jak takové pakety pozná). Paketový ovladač si na základě těchto "přihlášek" sestavuje seznam potenciálních příjemců datových paketů. Když pak skutečně přijme nějaký datový rámec, analyzuje jeho obsah a podle seznamu "přihlášených" se pak rozhoduje, komu předá paket, obsažený v rámci.
Pro funkční schopnosti paketových ovladačů je velmi podstatné, jakým způsobem rozpoznávají typ datových paketů a jak konkrétně postupují při jejich rozdělování mezi všechny potenciální příjemce.
Přesný algoritmus, podle kterého paketový ovladač postupuje, je sice poněkud komplikovanější, ale bez větší újmy na obecnosti lze říci, že příslušné rozhodování se děje jen na úrovni linkové vrstvy. Jinými slovy: paketový ovladač se rozhoduje podle údajů, obsažených v hlavičce datového rámce linkové vrstvy, ale již se nedívá "dovnitř" paketů, které jsou obsaženy v datové části těchto rámců (konkrétními typy datových rámců linkové vrstvy a rozpoznáváním jejich obsahu v případě sítí typu Ethernet jsme se podrobněji zabývali v minulém dílu tohoto volného seriálu).
Z toho pak vyplývá závažný důsledek: paketový ovladač například dokáže odlišit IP paket od IPX paketu (tj. paket, který patří síťovému protokolu IP z rodiny protokolů TCP/IP, odliší od paketu, který patří protokolu IPX ze soustavy protokolů IPX/SPX sítí Novell Netware). Co ale paketový ovladač již nedokáže odlišit, jsou například dva IP pakety, které patří různým instancím protokolu IP. V praxi to tedy znamená, že při použití paketového ovladače je možné souběžně provozovat více aplikací, ale tyto musí používat různé přenosové protokoly na úrovni síťové vrstvy (nebo mohou sdílet jednu sestavu přenosových protokolů, a potřebné rozdělování paketů mezi více potenciálních příjemců si musí zajistit vlastními silami na vyšší úrovni).
Uveďme si konkrétní příklad: při použití paketového ovladače můžeme vedle sebe provozovat například klientský shell sítě Novell NetWare (který pracuje s pakety IPX), a některou z verzí protokolu NFS pro MS DOS (např. PC-NFS, Beame&Whiteside NFS apod., které používají IP pakety). Tímto způsobem pak můžeme z jednoho počítače s MS DOSem získat současný a plně transparentní přístup jak k souborům na file serveru systému Novell NetWare, tak i k souborům na Unixovském file serveru. To je zvláště výhodné v případě, kdy potřebujeme jednoduchým způsobem kopírovat soubory z jednoho file serveru na druhý. Na pracovní stanici, která nám tuto možnost nabízí, si pak ale již nespustíme jiný program, který také používá síťový protokol IP, a sám si jej také implementuje (např. NCSA Telnet, NCSA FTP, klient systému Gopher, programy POPMail, Minuet apod.). Stále však máme možnost spustit si takový program, který dokáže využít již nainstalovanou implementaci protokolu IP (v našem konkrétním případě tu, která patří programu NFS).
Kde paketový ovladač končí, nastupuje PKTMUX!
Výše naznačené omezení paketových ovladačů může být v některých situacích dosti nepříjemné, a to hlavně při potřebě souběžného provozování více aplikací, které používají přenosové protokoly TCP/IP. Přitom právě pro tyto protokoly by dané omezení nemuselo existovat - stačilo by totiž, aby se paketový ovladač ráčil dívat také "dovnitř" datového paketu, jakmile pozná, že jde o IP paket. Zde by totiž našel takové informace, které by mu umožnily rozlišit mezi více potenciálními příjemci z řad instalovaných protokolů IP. Specifikace, vytvořená firmou FTP software, však toto nepředpokládá, a paketové ovladače to tudíž nedělají. V zájmu objektivnosti je ovšem třeba podotknout, že právě naznačená metoda není zcela korektní (existují totiž takové singulární případy, kdy ani "podívání se" dovnitř IP paketu nedává možnost správně se rozhodnout).
Přesto ale existují takové programy, které uvedenou "neschopnost" paketových ovladačů dodatečně kompenzují. Nejznámějším je program PKTMUX, vyvinutý ve výzkumném středisku Rutherford Appleton Laboratory (RAL) ve Velké Británii. Tento volně šiřitelný program (tj. freeware) funguje jako nadstavba nad paketovým ovladačem (instaluje se až po jeho zavedení), a chová se v jistém smyslu jako výhybka - od paketového ovladače přebírá všechny přijaté IP pakety, a ty pak sám rozděluje dále.
Rozhraní NDIS ovladačů
Další standard pro rozhraní mezi ovladačem síťové karty (či jiného síťového hardwaru) a protokoly vyšších vrstev vypracovaly společně firmy Microsoft a 3Com, a nazvaly jej NDIS (od: Network Driver Interface Specification, doslova: specifikace rozhraní síťových ovladačů). Vlastní ovladače, napsané podle tohoto standardu, jsou pak označovány jako tzv. NDIS ovladače (NDIS drivers).
Standard NDIS byl původně vypracován pro potřeby síťového operačního systému LAN Manager firmy Microsoft, a byl zveřejněn v květnu roku 1988. Má formu volně šiřitelného dokumentu (stejně jako specifikace rozhraní k paketovým ovladačům), a do dnešní doby prošel dalšími dvěma většími aktualizacemi (v současné době existuje verze 3.0). Stal se všeobecně uznávaným a dodržovaným standardem, a jeho použití rychle překročilo rámec jediného produktu, pro který byl vytvořen (LAN Manager-u). Dnes by si snad žádný výrobce nedovolil uvést na trh síťovou kartu, ke které by neexistoval NDIS ovladač. Na druhé straně podporuje standard NDIS i velká většina síťových programů, které jsou schopny pracovat s nezbytným síťovým hardwarem prostřednictvím NDIS ovladačů.
Jistou nevýhodou NDIS ovladačů je jejich relativně náročná instalace - z námi uvažovaných tří druhů ovladačů zřejmě nejnáročnější. Pro korektní instalaci a vlastní fungování NDIS ovladače jsou zapotřebí ještě dva další systémové programy (PROTMAN.SYS a NETBIND.EXE), a dále konfigurační soubor PROTOCOL.INI s popisem různých parametrů (který má formu textového souboru). Výrobce síťové karty ovšem musí napsat ke svému produktu jen vlastní NDIS ovladač, zatímco programy PROGMAN.SYS a NETBIND.EXE jsou volně šiřitelné (freeware) programy. Přesný způsob fungování NDIS ovladačů popisuje následující odstavec (nebo box: ..)
Jak funguje NDIS ovladač
Pro správné pochopení celkové koncepce standardu NDIS je vhodné si představovat, že síťový software je stavebnicí, ve které existují určité stavebnicové prvky, pravidla pro jejich skládání do větších celků, a také nástroje pro toto jejich skládání.
Pokud jde o stavebnicové prvky, tyto se v rámci standardu NDIS souhrnně označují jako ovladače (drivers), a jsou v zásadě dvojího druhu: tzv. protokolové ovladače (protocol drivers), které implementují jednotlivé sestavy protokolů (tj., přenosové protokoly vyšších vrstev, počínaje síťovou), a dále tzv. MAC ovladače (MAC drivers), které pracují na úrovni podvrstvy přístupu k přenosovému médiu (podvrstvy MAC), a přímo ovládají příslušný síťový hardware. Neformálně jsou pak právě tyto ovladače označovány jako NDIS ovladače.
 |
V prostředí MS DOSu mají MAC ovladače formu tzv. ovladačů zařízení (device drivers), zatímco protokolové ovladače mohou mít jak tuto formu, tak i formu běžných rezidentních programů v DOS-u, nebo formu aplikačních programů. Nejčastěji však i ony mají formu ovladačů zařízení (device drivers), které se instalují při zavádění systému prostřednictvím souboru CONFIG.SYS.
 |
Při instalaci jednotlivých ovladačů (v rámci "provádění" souboru CONFIG.SYS) však správce protokolů pouze shromažďuje potřebné údaje, které bude potřebovat pro vlastní propojení (binding) jednotlivých ovladačů, ale toto propojení zatím fakticky nerealizuje. To dělá až na explicitní příkaz. Ten mu může vydat v principu kterýkoli program, v praxi to ale bývá jen program NETBIND.EXE, spouštěný až při naběhnutí celého operačního systému (ať již ze souboru AUTOEXEC.BAT, z příkazové řádky či jinak).
Při vlastní práci v síti jsou pak data předávána mezi protokolovými ovladači a MAC ovladači takovým způsobem, aby bylo minimalizováno jejich kopírování z jedné vyrovnávací paměti (bufferu) do druhé. Pokud je to jen trochu možné, jsou předávány pouze ukazatele na příslušné vyrovnávací paměti.
Sdílení NDIS ovladačů
Až dosud jsme předpokládali nejjednodušší možnou konfiguraci: jednu síťovou kartu, jeden MAC ovladač (resp. NDIS ovladač), a jediný protokolový ovladač.
Standard NDIS počítá s tím, že protokolový ovladač může být sám tvořen z více částí (více dílčích protokolových ovladačů), které se budou skládat na sebe jako kostky pomyslné stavebnice. Zatím však nedefinuje žádné mechanismy pro vzájemné propojování (binding) těchto dílčích částí.
Další variantou, na kterou standard pamatuje, je možnost propojit jeden protokolový ovladač se dvěma MAC ovladači, každým pro jednu síťovou kartu (viz obrázek 3). Tato situace vychází vstříc takovým aplikacím, jako jsou různé mosty (bridges) a směrovače (routers).
 |
Právě naznačené řešení je určitě velmi univerzální. Vector se nesnaží sám rozhodovat o tom, komu datový paket patří, a toto rozhodnutí ponechává na mnohem kompetentnějších protokolových ovladačích. S realizací tohoto řešení je ale spojena nezanedbatelná režie, protože postupné nabízení všech paketů jednotlivým ovladačům určitou dobu trvá. Pořadí, ve kterém se Vector obrací na jednotlivé protokolové ovladače, je přitom dáno pořadím jejich instalace v rámci souboru CONFIG.SYS. Díky tomu je pak možné fungování celého mechanismu výrazně optimalizovat (instalovat jako první ty protokolové ovladače, které budou přijímat nejvíce paketů). Vyžaduje to o ovšem dosti hlubokou znalost fungování sítě, kterou lze jen těžko požadovat na běžném uživateli.
Rozhraní ODI ovladačů
Firma Novell uplatňovala u svého síťového operačního systému NetWare poměrně dlouhou dobu přístup "až na holé železo" - svůj síťový protokol IPX implementovala tak, že přímo pracoval s konkrétní síťovou kartou. Teprve v relativně nedávné době, a snad i pod tlakem konkurenčního LAN Manageru, změnila názor a umožnila použití samostatných ovladačů. Ve spolupráci s firmou Apple Computer si za tímto účelem vyvinula vlastní rozhraní k těmto ovladačům, které nazvala ODI (Open Data-Link Interface, někdy též: ODLI). První předběžná verze specifikací tohoto rozhraní pochází z roku 1988, oficiální verze je z roku 1989, a první ovladače, vyhovující těmto specifikacím, se objevily v roce 1990.
Síťové produkty firmy Novell začaly přecházet z původní koncepce tzv. dedikovaného IPX (neboli síťového protokolu IPX, který si sám obsluhuje síťovou kartu) na používání nových ODI ovladačů postupně. V sítích NetWare verze 3.11 je možné používat kterýkoli z obou přístupů, zatímco v nové verzi 4.0 již jen ODI ovladače.
Firma Novell přitom zavedla zajímavou praxi: po patřičném ověření certifikuje ovladače jednotlivých síťových karet, a tím vlastně poskytuje svou vlastní záruku na jejich korektní fungování (i když je píší výrobci síťových karet). Činila tak původně i u tzv. dedikovaných IPX ovladačů, ale od června 1992 již certifikuje pouze ODI ovladače.
Zajímavý je také obvyklý způsob, jakým výrobci síťových karet píší ODI ovladače ke svým výrobkům. Vlastní standard rozhraní ODI byl plně zveřejněn, a každý výrobce si tedy může napsat potřebný ovladač zcela sám. V praxi si ale za tímto účelem nejspíše zakoupí od firmy Novell vývojový "kit" (LAN Driver Toolkit), se kterým dostane některé části ODI ovladače ve zdrojovém tvaru, a k nim pouze připíše ty části, které se bezprostředně týkají konkrétního hardwarového řešení, a jsou pro něj specifické. Podrobněji je tato otázka rozváděna v následujícím odstavci (resp. v boxu: ....)
Jak funguje ODI ovladač
 |
- ovladač síťové karty, označovaný jako MLID (Multiple Link Interface Driver). V užším slova smyslu je jako ODI ovladač označován právě tento programový modul,
- modul LSL (Link Support Layer), fungující jako mezičlánek mezi ovladačem síťové karty a protokoly vyších vrstev
- sestava protokolů (tzv. protokol stack), implementující přenosové protokoly vyšších vrstev (síťovou vrstvou počínaje).
Možnosti vzájemného propojení všech těchto modulů ukazuje obrázek 4. Z něj je také možné vytušit, že hlavním úkolem ovladačů síťových karet (MLID) je bezprostřední obsluha síťových karet a zpracování rámců linkové vrstvy, ze kterých při příjmu "vybalují" datové pakety (které samy nijak neinterpretují), a předávají je modulu LSL. Ten pak rozhoduje o tom, kterému protokolu vyšších vrstev (resp. které sestavě protokolů) bude každý jednotlivý paket předán.
Samotný ovladač (MLID) je vesměs realizován jako jeden programový modul (ve formě rezidentního programu, případně i instalovatelného ovladače zařízení, neboli tzv. device driveru). Interně je ovšem tvořen ze tří částí (viz obr. 5):
- modulu MSM (Media Support Module), který řeší to, co je pro všechny ovladače společné (především pak vazbu na modul LSL a operační systém, inicializaci atd.),
- modulu TSM (Topology Specific Module), který zajišťuje to, co je specifické pro konkrétní přenosovou technologii (např.: sériovou linku, síť typu Ethernet, Token Ring, FDDI apod.), tedy například přidávání či naopak odstraňování hlaviček linkových rámců apod., a
- modul HSM (Hardware Specific Module), který zajišťuje bezprostřední ovládání síťového hardwaru.
 |
Výrobce síťové karty, který si od firmy Novell zakoupí potřebný vývojový "kit", však musí sám napsat pouze modul HSM. Zdrojový tvar ostatních dvou modulů totiž dostane v rámci zakoupeného "kitu".
Jednou ze zajímavých charakteristik celého rozhraní ODI je jeho snaha o maximální univerzálnost, spočívající ve vědomém zakrývání specifik používané přenosové cesty před protokoly vyšších vrstev. Tyto sestavy protokolů (protocol stacks) tedy neví o tom, jakým konkrétním způsobem jsou data v síti skutečně přenášená, a díky tomu pak mohou být stejné pro různé přenosové technologie (např. pro Ethernet, Token Ring, FDDI apod.). Potud je toto řešení jistě velmi výhodné. Na druhé straně ale zastírání všech případných odlišností a vytváření dojmu jednotnosti nemůže být zadarmo, a jde tedy nutně na úkor efektivnosti přenosů jako takových.
Sdílení ODI ovladačů
 |
Velmi zajímavý je způsob, jakým jsou ve standardu ODI rozlišovány různé druhy paketů (pro potřeby jejich rozdělování mezi více potenciálních příjemců z řad sestav protokolů vyšších vrstev). Pakety jsou rozlišovány na základě síťového protokolu, podle kterého jsou sestaveny. Každý takovýto protokol má přiřazen číselný identifikátor (Protocol ID), ale konkrétní hodnota tohoto identifikátoru je závislá i na druhu používané přenosové technologie (přesněji: na druhu rámce, používaného na úrovni linkové vrstvy). Například u sítí typu Ethernet s linkovým rámcem Ethernet_II je tímto identifikátorem obsah 13. a 14. bytu rámce (udávající typ datového paketu, viz minulý díl této série článků), zatímco v případě rámců IEEE 802.3 s rámci 802.2 je to obsah jednobytového pole DSAP (Destination SAP, neboli přechodový bod příjemce).
Tím, kdo přijaté rámce podle jejich typu (identifikátoru) skutečně rozděluje mezi více různých sestav protokolů, je modul LSL. V zásadě tak činí na základě požadavků, které mu jednotlivé sestavy protokolů předají ve fázi inicializace celého rozhraní.
Požadavek konkrétní sestavy protokolů na příjem paketů může být v zásadě trojího druhu:
- tzv. prescan režim (doslova: režim předběžné prohlídky), při kterém daná sestava protokolů požaduje, aby jí byl nabídnut každý přijatý paket, ona jej "prohlédne", a pak si jej podle vlastního uvážení buď nechá, nebo jej zase vrátí modulu LSL, který jej může nabídnou dalším zájemcům,
- tzv. bound režim (doslova: vázaný), kdy se sestava protokolů přihlásí u modulu LSL s požadavkem na odběr paketů určitého konkrétního typu (vyjádřeného příslušným identifikátorem), nebo
- tzv. default (tj. implicitní) režim, při kterém sestava protokolů přijímá všechny pakety, které zbydou.
Jedna sestava protokolů se může přihlásit k odběru paketů od jedné či více síťových karet (resp. ovladačů MLID). Pro každou kartu však smí požadovat režim "prescan" nejvýše jedna sestava protokolů, a stejně tak i pro režim "default". K příjmu paketů různých typů z jedné a téže karty v tzv. vázaném (bound) režimu se může přihlásit více sestav protokolů.
Modul LSL pak při přijetí každého paketu postupuje tak, že jej nejprve nabídne sestavě protokolů, která se přihlásila k odběru v režimu "prescan". Pokud tato paket odmítne (nebo vůbec neexistuje), předá modul LSL datový paket té sestavě protokolů, která se přihlásila k odběru příslušného typu paketů v režimu bound. Pokud žádná taková sestava protokolů neexistuje, předá LSL paket implicitní sestavě protokolů (tj. té, která se přihlásila k odběru v tzv. default režimu).
Zde se ovšem nabízí zajímavá otázka: mají-li být všechny sestavy protokolů zcela nezávislé na konkrétní přenosové technologii, jak potom mohou znát konkrétní číselné identifikátory typů paketů, se kterými mají pracovat, když tyto jsou na přenosové technologii závislé? Například pro IPX rámce, přenášené v síti Ethernet (s linkovými rámci Ethernet_II) má příslušný identifikátor (Protocol ID) hodnotu 8137 hexadecimálně, zatímco v případě sítí Token Ring má hodnotu EO (taktéž hexadecimálně)?
Řešení je vcelku jednoduché: sestavy protokolů nemají v sobě příslušné identifikátory pevně zabudovány. Místo toho je získávají až prostřednictvím konfiguračního souboru (NET.CFG), kde je pro ně připravují uživatelé (resp. správci sítě).
Závěrem
V článku, který se zabývá různými druhy ovladačů síťových karet, by nejspíše neměl chybět výčet alespoň těch nejznámějších síťových programů s uvedením toho, jaké druhy ovladačů podporují.
Každý takovýto seznam ale vždy bude neúplný a neaktuální již v okamžiku jeho sestavování - situace se totiž mění skutečně den ze dne, a zcela zákonitě směřuje k tomu, že každý síťový program bude podporovat každý druh síťového ovladače. Ovšem i v případě, kdy určitý konkrétní síťový program zatím nepodporuje určitý konkrétní druh ovladačů, není ještě zdaleka nic ztraceno: existují totiž takové programy, které převádí jedno rozhraní k síťovým ovladačům na jiné. V angličtině se jim říká příznačně shims (doslova: podložky, vyrovnávací mezičlánky).
Představme si například, že provozujeme program, který je schopen pracovat jen s tzv. NDIS ovladači, ale k naší síťové kartě máme k dispozici pouze tzv. ODI ovladač. Nevadí - po instalaci tohoto ODI ovladače si nainstalujeme ještě převodník mezi ODI a NDIS ovladači (konkrétně: program ODINSUP). Výsledný efekt je pak v zásadě takový, jako kdybychom použili skutečný NDIS ovladač.