Paralelizace datových přenosů přes rozlehlé vysokorychlostní sítě

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Diplomová práce Paralelizace datových přenosů přes rozlehlé vysokorychlostní sítě Martin Čížek

Poděkování Rád bych poděkoval Ing. Antonínu Královi za vedení diplomové práce, množství užitečných rad a poznámek, Dr. Ing. Svenu Ubikovi za konzultace výzkumného záměru, sdružení Cesnet, z.s.p.o. za poskytnutí prostoru a prostředků k řešení projektu a Pavlu Vodrážkovi za pomoc s kreslením obrázků. Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze literaturu a podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). Praha, 27. 1. 2005 Podpis / Signature

Anotace Paralelizace datových přenosů přes rozlehlé vysokorychlostní sítě Práce se zabývá paralelizací datových přenosů v počítačových sítích, zejména přístupem, kdy je paralelní přenos explicitně řízen koncovými stanicemi. Diskutovány jsou možnosti paralelizace na různých komunikačních vrstvách a je navržen systém provádějící paralelizaci nad transportní vrstvou. Systém také slouží jako framework pro implementaci různých paralelizačních přístupů. Dále je rozebírána realizace navržené architektury paralelizačního subsystému, jeho způsobu použití a měření vlastností. Klíčová slova: Paralelní přenosy, rozlehlé vysokorychlostní sítě Abstract Parallelization of data transfers over wide-area high-speed networks This paper is concerned with the parallelization of data transfers in computer networks, especially with the approach where the parallelization is explicitly controlled by end stations. Parallelization alternatives on different communication layers are discussed. A system that allows parallalelization upon the transport layer and provides a framework for implementation and testing of various parallelization approaches is then designed. Successive sections analyze the implementation of the proposed parallelization subsystem architecture, its usage and measurements of characteristics. Keywords: Parallel transfers, wide-area high-speed networks

5 Obsah 1 Paralelizace datových přenosů 9 1.1 Motivace k paralelizaci přenosů........................ 9 1.1.1 Terminologie.............................. 9 1.1.2 Neřízený paralelizmus......................... 9 1.1.3 Paralelní přenos explicitní řízení paralelizmu............ 10 1.1.4 Přenosy přes rozlehlé vysokorychlostní sítě.............. 10 1.1.5 Shrnutí................................. 11 1.2 Možnosti paralelizace.............................. 11 1.2.1 Paralelizace na síťové vrstvě...................... 11 1.2.2 Paralelizace na transportní vrstvě................... 12 1.2.3 Paralelizace na aplikační vrstvě.................... 13 1.3 Vrstva podpory paralelních přenosů...................... 15 1.3.1 Požadavky kladené na paralelizační vrstvu.............. 15 2 Návrh systému 17 2.1 Způsob dělení dat do dílčích přenosů..................... 17 2.1.1 Deterministické dělení......................... 17 2.1.2 Nedeterministické dělení........................ 18 2.2 Kontext provádění protokolu.......................... 18 2.2.1 Provádění protokolu v kontextu aplikačního programu........ 19 2.2.2 Asynchronní provádění protokolu................... 19 2.3 Architektura systému.............................. 20 2.3.1 Komunikace s vláknem protokolu................... 20 2.3.2 Sdílení soketů dílčích přenosů..................... 21 2.3.3 Rozvrh paralelního přenosu...................... 22 2.4 Řídicí komunikace s protistranou....................... 23 2.5 Životní cyklus paralelního spojení....................... 24

6 2.5.1 Stavy paralelního spojení........................ 24 3 Implementace 30 3.1 Pojmy a struktury............................... 30 3.2 Vlákno protokolu................................ 32 3.2.1 Události................................. 32 3.2.2 Reakce na událost............................ 34 3.2.3 Ovladač paralelního přenosu...................... 35 3.3 Library Space.................................. 37 4 Vlastnosti paralelních přenosů 39 4.1 Paralelní přenosy po jedné fyzické trase.................... 39 4.1.1 Přenos beze ztrát............................ 39 4.1.2 Přenos se ztrátami........................... 41 4.2 Paralelní přenosy po více fyzických trasách.................. 44 5 Závěr 46 5.1 Další výzkum.................................. 46 A Příklady 48 A.1 Příklad aplikačního paralelizmu........................ 48 B Programátorské rozhraní 49 B.1 Knihovna psock-mt............................... 49 B.2 Testovací nástroj psock-testperf........................ 52 C Obsah CD-ROM 53

7 Seznam obrázků 2.1 Architektura systému psock.......................... 21 2.2 Přechodový diagram paralelního soketu (zjednodušeno)........... 27 2.3 Navazování paralelního spojení........................ 28 2.4 Ukončování paralelního spojení........................ 29 3.1 Vztahy struktur v Protocol Space....................... 32 3.2 Princip algoritmu pollall............................ 35 3.3 Vztahy struktur v Library Space....................... 38 4.1 Propustnost v závislosti na počtu dílčích přenosů při různých hodnotách okénka...................................... 41 4.2 Propustnost v závislosti na sumárním okénku................ 42 4.3 Nárůst okénka.................................. 43 4.4 Propustnost v závislosti na počtu dílčích přenosů při ztrátovosti 0,01%.. 44 4.5 Propustnost dvou tras v závislosti na rozdělení kapacity........... 45

8 Seznam tabulek 2.1 Příklad rozvrhu paralelního přenosu...................... 22 4.1 Konfigurace měření paralelních přenosů po jedné fyzické trase....... 40 4.2 Konfigurace měření paralelních přenosů po ztrátové trase.......... 44

9 Kapitola 1 Paralelizace datových přenosů 1.1 Motivace k paralelizaci přenosů Paralelizmus datových přenosů v sítích představuje jejich přirozenou vlastnost. Je dán jednak vlastní redundancí přenosových linek, jednak sdílením přenosového média, zejména pomocí časového a frekvenčního multiplexu. V dalších úvahách se zaměříme na paketové Best-Effort sítě a TCP/IP jako nejrozšířenějšího představitele. 1.1.1 Terminologie Následující seznam uvádí základní použitou terminologii ve vztahu k paralelním přenosům obecně. Logický přenos poskytuje spolehlivý přenos dat rourou. Jedná se buď o klasický přenos nebo o paralelní přenos. Paralelní přenos je logický přenos, který ke své funkci používá několik přenosů dílčích. Dílčí přenos je komponentou paralelního přenosu. Jaká data po něm putují, jejich formát atd., určuje konkrétní implementace paralelního přenosu. Klasický přenos je logický přenos reprezentovaný TCP spojením. 1.1.2 Neřízený paralelizmus Předpokládejme, že provoz na síti se skládá z řady méně náročných, nezávislých logických přenosů, intenzita zpráv λ [zpráv/sec] na trasách mezi dvojicemi uzlů má náhodný charakter a její střední hodnota v čase příliš nekolísá.

1.1 Motivace k paralelizaci přenosů 10 Tyto podmínky jsou ideální pro klasické využití síťového paralelizmu. Rozložení toků v síti je v hrubém měřítku dáno z vnějšku; určuje jej statická a dynamická 1 konfigurace sítě. Pomocí vhodného uspořádání lze dosáhnout příznivé sumární propustnosti, malého středního zpoždění, nižšího zatížení jednotlivých tras a vyšší spolehlivosti. 1.1.3 Paralelní přenos explicitní řízení paralelizmu V případech, kdy pro logický přenos je požadována velká kapacita sítě nebo požadavky na náročnější přenosy vznikají mezi různými uzly a nárazově, kýžené vlastnosti paralelizmu pro náročný přenos klasickým způsobem nezískáme. K jejich dosažení je potřeba zabývat se cíleným využitím síťového paralelizmu pro logický přenos. Kromě zlepšení vlastností samotných přenosů pak též lze dosáhnout rovnoměrnějších nároků na síťovou infrastrukturu, nebo naopak maximálního vytížení kapacity části sítě. V komunikačních systémech, kde existuje více využitelných fyzických tras, znamená paralelizace datových přenosů jedinou možnost, jak v rámci logického přenosu překonat limity jednotlivých tras. 1.1.4 Přenosy přes rozlehlé vysokorychlostní sítě Další požadavky na paralelizaci pramení z vlastností používané síťové infrastruktury. Nejrozšířenější transportní protokol TCP vykazuje v oblasti přenosů přes rozlehlé vysokorychlostní sítě některé nepříjemné vlastnosti: Při použití přenosových bufferů s kapacitou menší než je kapacita trasy 2 nedostáváme plný výkon. Při použití přenosových bufferů s kapacitou větší než je kapacita trasy též obvykle dostaneme suboptimální výkon, neboť řízení zahlcení (congestion control) způsobuje oscilace velikosti okénka (congestion window) [1]. Přestože existuje mnoho úprav TCP pro zlepšení jeho vlastností, ne vždy je možné je aplikovat. 3 Paralelizace tyto nedostatky pochopitelně nevyřeší, nicméně může značnou měrou snížit jejich projevy. 1 Na síťové úrovni jsou to směrovací protokoly a policy routing. U aplikačního modelu klient-server stojí za zmínku škálování pomocí časově a geograficky proměnných DNS překladů. Předním dodavatelem tohoto řešení je společnost Akamai, používá je např. vyhledávač Google. 2 Součin bandwidth.delay, viz část 4.1.1. 3 Aplikaci úprav je potřeba provést u obou koncových stanic.

1.2 Možnosti paralelizace 11 1.1.5 Shrnutí Ačkoliv je paralelizmus na různých úrovních již nasazen, má smysl jej nadále zkoumat. Jednak kvůli prudkému rozvoji síťových technologií, jednak pro možnosti, jež získáme jeho explicitním řízením. 1.2 Možnosti paralelizace Paralelizaci datových přenosů lze provádět mnoha způsoby; zde rozebereme několik možností opírajících se o architekturu klasických sítí TCP/IP. 1.2.1 Paralelizace na síťové vrstvě Podpora redundance tras ve směrovačích a operačních systémech je dnes samozřejmostí. Modernější systémy podporují rozkládání zátěže (load balancing), tedy explicitní využití síťového paralelizmu. Paralelizaci na síťové vrstvě lze řídit právě pomocí pravidel pro load balancing. Pravidla rozkládání zátěže by měla zachovávat příslušnost datagramů každého přenosu k jedné zvolené trase; jinými slovy, jsou-li X a Y dva datagramy náležící témuž přenosu, pro oba by měl být použit stejný záznam směrovací tabulky. V opačném případě se síť pro transportní protokol jeví nestabilně, selhává např. predikce RTT a neuplatní se různé heuristiky vycházející z předpokladu slušného chování sítě (FIFO). Důsledkem je pochopitelně nepříznivý vliv na výkon transportního protokolu [6]. Jestliže ale má být zachována příslušnost daného přenosu k určité trase, není možné jej paralelizovat. Řešení je tedy potřeba hledat na vyšších vrstvách síťového modelu. Dostupné implementace Jádro OS Linux síťový subsystém iproute2 implementuje policy routing; výběr směrovacích tabulek lze kromě běžných pravidel (zdrojová IP adresa) provádět pomocí hodnoty fwmark 4, PF: The OpenBSD Packet Filter, směrovače, např. Cisco IOS Server Load Balancing (SLB). 4 Číselná značka, kterou paket udržuje po dobu svého života v jádře. Lze ji libovolně nastavovat v subsystému netfilter (filtrování paketů v Linuxu).

1.2 Možnosti paralelizace 12 1.2.2 Paralelizace na transportní vrstvě Poznámka 1.1 Striktně vzato, až na této úrovni lze hovořit o paralelních přenosech, neboť na nižších vrstvách nejsou přenosy definovány. Na transportní vrstvě se lze rozdílným parametrům jednotlivých přenosových tras přizpůsobit, navíc sledováním těchto parametrů lze paralelní přenos inteligentně optimalizovat. Využití existujícího transportního protokolu Pro jednotlivé konkurentní přenosy, resp. trasy lze použít existující transportní protokol. Podpora paralelních přenosů pak bude tvořit komunikační mezivrstvu, která bude používat existující transportní vrstvu podobně jako klasické aplikace, nicméně pro skutečnou aplikaci bude poskytovat funkcionalitu transportní vrstvy. Jako transportní protokol dílčích přenosů se nabízí TCP. Jeho uplatněním lze získat jisté výhody: využití prověřené a všeobecně přijaté metody přenosu, implementované řízení toku pro jednotlivé dílčí přenosy, lepší koexistence s ostatním provozem na síti (spravedlnost, stabilita), průchodnost síťovou infrastrukturou (přes různé stavové firewally, NAT N:1 apod.). Z použití TCP zároveň plynou možné nevýhody: Všeobecně přijatá metoda přenosu může mít své nedostatky (viz sekce 1.1.4 na str. 10). Ačkoliv projevy některých nedostatků lze paralelizací odbourat 5, vlastní slabiny samozřejmě přetrvají. Řízení toku jednotlivých přenosů nemusí být pro logický přenos jako celek optimální. Případné retransmise se provádí vždy po stejném (a potenciálně problémovém) spojení, na němž se paket ztratil. Potvrzení paketů odcházejících určitou trasou se vždy vracejí toutéž. Bez tohoto omezení by bylo možné získat určitý prostor pro zefektivnění paralelního přenosu. Uspořádání přijatých paketů se nejprve provádí na jednotlivých TCP spojeních. Pokud paket nebo skupina paketů na spojení předběhne, TCP musí počkat na všechny nepřijaté pakety s nižším sekvenčním číslem; pak teprve předá data nadřazené vrstvě. Nicméně nadřazenou vrstvou je právě diskutovaná vrstva paralelizační, která by eventuálně uměla naplánovat i takto předběhlé pakety dříve. 5 A také je to naším cílem.

1.2 Možnosti paralelizace 13 Dostupné implementace PSockets C++ knihovna pracující nad TCP sokety, implementuje dělení dat do bloků konstantní délky metodou round-robin. 6 Klade si za cíl dosáhnout výkonu, jaký by síť měla s optimálně vyladěnými parametry (zejména velikost bufferů pro TCP okénka), bez nutnosti vlastní změny parametrů. Vytyčený cíl knihovna plní; nicméně způsob, kterým jej dosahuje, je v podstatě jen změna parametrů sítě (zvětšení sumárního okénka a úprava koeficientů výpočtu Window a Threshold). Použitý algoritmus je vhodný pro přenosy po jedné společné trase. Průměrná celková propustnost paralelního přenosu je dána n-násobkem propustnosti nejpomalejšího dílčího přenosu, kde n je počet dílčích přenosů. To pochopitelně představuje omezení, pokud mají dílčí přenosy různé podmínky (různé fyzické trasy, stochastická frontová disciplína na trase,... ). V případě identických podmínek pro dílčí přenosy může tento přístup být výhodný díky stabilitě jejich zatížení. 1.2.3 Paralelizace na aplikační vrstvě Zatímco transportní vrstva může paralelně přenášet jen data v rámci přenosových bufferů, aplikační vrstva může využít skutečného paralelizmu daného podstatou problému, který řeší. 7 Vždy se ale jedná o vlastnost specifickou pro konkrétní aplikaci, a proto její využití zůstává na programátorech. Poznámka 1.2 S ohledem na použitou terminologii nepředstavují paralelně využívaná aplikační spojení paralelní přenos, ale jsou chápána jako nezávislé klasické přenosy. Uplatnění aplikačního paralelizmu Přestože aplikace s vlastním paralelizmem má potenciál výhodně využít paralelizmu síťového, narážíme na praktická omezení. Aby aplikace mohla efektivně využít přenosového paralelizmu, je potřeba vyřešit zejména tyto otázky: Bude umět namapovat své potřeby na konkrétní infrastrukturu? Bude nezávislost dat procházejících různými přenosy skutečně velká? Ukázku aplikace, kde tomu tak není, uvádí příklad A.1 na str. 48. 6 V terminologii autorů PSockets je přístup nazýván network stripping. 7 Nemusí se nutně jednat o komplikované paralelní algoritmy. Rozhodující je dostupnost vzájemně nezávislých zdrojů/konzumentů dat, a to na obou stranách. Může jít i o obyčejný soubor stačí jej vícenásobně otevřít, pozice jednotlivých otevřených souborů vhodně nastavit voláním lseek() a dále číst z různých pozic, resp. zapisovat do různých částí souboru najednou.

1.2 Možnosti paralelizace 14 Lze optimálně využít všech přenosů? Pokud aplikace bude využívat některá spojení na maximum, zatímco jiná zanedbatelně, neplní náš záměr. Bude umět přemapovat data na různé přenosy? Jako příklad, kdy je přemapování žádoucí, může posloužit přenos souboru dvěma spojeními po dvou fyzických trasách. Předpokládejme, že soubor je přenášen po polovinách a že první trasa je 2x rychlejší než druhá. Lze snadno nahlédnout, že bez přemapování bude přenos trvat až o polovinu déle. Nebude suplovat funkčnost paralelizace na transportní vrstvě? Výše uvedené problémy lze samozřejmě vyřešit. Obnáší to ale psaní nepříjemného kódu, který nakonec plní funkce paralelizace na transportní vrstvě. Stojí proto za zvážení, zda tyto starosti raději nepřenechat dedikovanému subsystému. Podpora nezávislých aplikačních přenosů Potřebuje-li aplikace přenášet více toků naráz, může vytvořit příslušný počet soketů a otevřít potřebná spojení. Navazovat nová spojení je ale bohužel drahé, nepříjemné a v dnešní době firewallů a NATů často problematické. 8 Na to mysleli autoři protokolu SCTP [8]. SCTP umožňuje přenos více nezávislých toků v rámci jedné asociace. Dostupné implementace Příkladů existuje řada, zde je několik vybraných: GridFTP [11], bbftp [10] přenosy souborů s podporou paralelních datových toků, pscp [5] rozšíření scp o podporu paralelních přenosů, HTTP 1.0 a vyšší v požadavku lze uvést hlavičku Range a vyžádat tak určitou část objektu. Pokud server vyhoví, odpoví kódem 206 (Partial Content) a v hlavičkách upřesní, jaký rozsah posílá. Ačkoliv tato vlastnost není primárně určena k paralelním přenosům, mnoho tzv. download managerů ji k tomu využívá. 8 Z těchto důvodů se často od nezávislých přenosů upouští a nezávislá data se přenášejí sekvenčně jedním spojením. Později posílané zprávy se tak stávají zcela závislé na přenosu a doručení dřívějších zpráv.

1.3 Vrstva podpory paralelních přenosů 15 1.3 Vrstva podpory paralelních přenosů Snahou je poskytnout aplikacím možnost využívat paralelní přenosy bez podstatnějších změn jejich struktury. Vrstvu podpory paralelních přenosů je tedy potřeba začlenit pod aplikační vrstvu 9. Paralelizace na síťové vrstvě (sekce 1.2.1) též není pro naše účely vhodná, zvoleno tedy bylo řešení na, resp. nad transportní vrstvou (sekce 1.2.2). Pro dílčí přenosy je použito TCP, zejména pro dostupnost, rozšířenost a snadnou implementovatelnost. Nevýhody použití TCP zmíněné v 1.2.2 lze v současné fázi vývoje zanedbat. Uplatnění TCP též dovoluje zkoumat chování paralelních přenosů ve vztahu ke klasickým TCP přenosům. 1.3.1 Požadavky kladené na paralelizační vrstvu Řešení by mělo vyhovovat následujícím nárokům: flexibilita paralelního přenosu, možnost nastavovat parametry voláním API, jednoduchost pro uživatele použití vycházející ze standardního rozhraní BSD soketů. Ani specifická volání API by většinou neměla být nutná v případě testů existujících aplikací se systémem by implicitní parametry mělo být možné nastavit pomocí konfiguračního souboru knihovny, možnost použití alternativních algoritmů a strategií dělení dat mezi přenosy a jejich rekonstrukce. Možnosti na této úrovni jsou rozmanité, proto by knihovna měla zároveň sloužit jako framework pro implementaci dalších algoritmů/strategií, schopnost automatického vyjednání parametrů (počet dílčích přenosů, algoritmus) při spojování, možnost relativně snadného vývoje alespoň v počátečních fázích, malá zátěž CPU a sběrnic, maximálně konkurentní běh všech komponent. Tzn. instance protokolu paralelních přenosů nesmí omezovat (blokovat) aplikaci ani sebe navzájem. Naopak činnost/nečinnost aplikace nesmí blokovat protokol. Framework pro alternativní algoritmy paralelního přenosu musí umožňovat vzájemné neblokování jednotlivých přenosů (ačkoliv konkrétní algoritmus může definovat závislosti), zobecnitelnost; struktura systému by měla posloužit dalšímu výzkumu, měla by se hodit i pro případnou implementaci v jádře OS. 9 Zde máme na mysli funkční význam vrstvy; technicky může implementace pracovat právě na aplikační vrstvě.

1.3 Vrstva podpory paralelních přenosů 16 Základy architektury by mělo být možné použít pro tato na sebe navazující zobecnění: 1. oddělení kontextu řízení paralelizačního protokolu a uživatele paralelního soketu na různé výpočetní uzly, 2. uživatelem paralelního soketu se stane více uzlů; jinými slovy data bude generovat/zpracovávat více uzlů, ale protokol se bude provádět centrálně, 3. plná distribuce provádění protokolu (tzn. i protokol se bude provádět na více uzlech).

17 Kapitola 2 Návrh systému Tato kapitola se zabývá koncepcemi realizace paralelizačního systému postaveného nad transportní vrstvou (viz sekce 1.3 na str. 15). Diskutovány jsou klíčové funkce systému, možnosti, jak je uskutečnit, a zvolená řešení. Deklarace záměru. Cílem je vytvořit knihovnu podpory paralelních přenosů pro uživatelské aplikace splňující požadavky ze sekce 1.3.1. Dílčí přenosy budou uskutečněny protokolem TCP s využitím standardních BSD soketů. Hlavním výstupem bude sdílená knihovna a příslušné hlavičkové soubory. Implementační platforma. Projekt je implementován v jazyce C a používá POSIX vlákna. Hlavní vývojovou a testovací platformou pro koncové stanice je OS Linux. Plánovány jsou také testy na jiných systémech. 2.1 Způsob dělení dat do dílčích přenosů Jedním z požadavků na systém je podpora více algoritmů paralelního přenosu. Mezi nejdůležitější charakteristiky algoritmu patří strategie dělení dat do dílčích přenosů. Aby systém mohl pokrýt různé přenosové algoritmy, je vhodné způsoby dělení dat do přenosů zmapovat. 2.1.1 Deterministické dělení V případě deterministického dělení vysílač v každém okamžiku ví, kterým dílčím přenosem bude odesílat následující blok dat. Přijímač zase vždy zná dílčí přenos, z něhož získá očekávaná data. Mezi algoritmy s deterministickým dělením patří round-robin a jeho modifikace. i-tý blok se pošle i mod n -tým dílčím přenosem. Bloky mohou mít konstantní nebo variabilní

2.2 Kontext provádění protokolu 18 velikost. Variabilní velikost bloku umožňuje paralelní přenos přizpůsobovat požadavkům aplikace a stavu sítě (na základě statistických údajů). Na druhou stranu bloky o variabilní délce je potřeba doplnit o údaj s jejich délkou. Další informace o algoritmu round-robin se nachází v sekci 3.2.3 na str. 35. 2.1.2 Nedeterministické dělení V tomto případě přijímač a/nebo vysílač nemusí vždy znát dílčí přenos použitý pro následující transfer. Typickým příkladem nedeterministického dělení je řešení, kdy je použitý přenos určován oznámením nižší vrstvy o připravenosti k odeslání/příjmu (tento přístup tvoří základ algoritmu pollall sekce 3.2.3 na str. 35). Nedeterministické dělení je flexibilnější než deterministické, umožňuje algoritmu okamžitou reakci na změny v síti a jiné události, usnadňuje případnou rekonfiguraci paralelního přenosu. Naproti tomu vyžaduje, aby s jednotlivými bloky byla přenášena i synchronizační informace (např. v podobě číslování bloků), což také klade vyšší nároky na výpočetní výkon koncových stanic. Ověření funkce. Účinnost přenosu pomocí paralelních TCP spojení a metody roundrobin ukazuje [13]. Pro ověření základních vlastností paralelního přenosu s nedeterministickým dělením přenášených dat byla vytvořena zjednodušená verze paralelizačního systému. Implementován byl algoritmus, který odesílá bloky dle připravenosti soketů, a byla provedena základní měření [3]. Nároky na systém. Je zřejmé, že různé přístupy distribuce dat v rámci paralelního přenosu kladou různé nároky na činnost systému. Zatímco deterministické je méně náročné a většina operací pro jeho zajištění navazuje na aplikační volání systému, u nedeterministického dělení je obvykle potřebné řadu úkonů provádět nezávisle na běhu aplikace. Dělení a rekonstrukce přenášených dat představují klíčové úkoly protokolu paralelizačního systému, a jsou proto zohledněny i v následující sekci, věnované způsobu implementace protokolu. 2.2 Kontext provádění protokolu Běh systému tohoto druhu vyžaduje uchovávat mnoho stavových informací a reagovat na různé události jako připravenost dílčího přenosu či zprávu protistrany. Obecně tuto činnost budeme nazývat provádění protokolu.

2.2 Kontext provádění protokolu 19 2.2.1 Provádění protokolu v kontextu aplikačního programu Tento způsob lze též označit jako synchronní provádění, neboť místa přechodů mezi aplikačním programem a kódem realizujícím protokol jsou jasně dána. Při provádění netriviálního protokolu v rámci volání sdílené knihovny hrozí, že jeho funkce utrpí dlouhými intervaly mezi knihovními voláními a že v okamžicích volání naopak vzniknou zbytečné prostoje. 1 Mezi možnosti, jak tyto potíže zmírnit, patří: Kooperace ze strany aplikace v podobě konvencí používání speciálních knihovních volání (hooků). Na unixových systémech jsou obzvlášť výhodné funkce (wrappery, obálky) obalující volání poll(), select(), sleep() apod. Knihovna pak může čekat na časové události ( timeouty ) spolu s událostmi na svých a uživatelových souborových deskriptorech najednou. Tato metoda je implementována např. v knihovně sctplib [9]. Programování řízené událostmi. Uživatel knihovně oznámí události, které jej zajímají, a obslužné funkce (handlery, callbacky), které je budou obsluhovat. Poté předá knihovně řízení. Při výskytu daných událostí knihovna volá obslužné funkce oznámené aplikací. V podstatě se ale jedná o původní problém obrácený naruby. V předchozím případě mohl uživatel zablokovat protokol nevoláním knihovních funkcí. Tentýž efekt nastává i v tomto případě, pokud aplikační obsluha trvá neúměrně dlouho. Metoda je vhodná tam, kde je běh programu zcela podřízen síťovým událostem. Využívá ji opět sctplib [9] nebo např. LIBPCAP [12]. 2.2.2 Asynchronní provádění protokolu V tomto případě je kód protokolu aktivován nezávisle na běhu aplikace, ta se tedy nemusí o nic starat. Vzhledem k požadavkům ze sekce 1.3.1 a nárokům různých přístupů dělení dat bylo zvoleno právě toto řešení. Asynchronní provádění protokolu lze technicky zajistit dvěma způsoby. Prvním z nich je přímá aktivace kódu protokolu, zejména pomocí přerušení. Tato metoda se používá v jádře operačního systému; v omezené míře ji lze použít i v uživatelském prostoru při vhodném nastavení generování a obsluh signálů. 2 Druhým způsobem je provádění protokolu v samostatném vlákně, kdy se o přepínání kontextu stará operační systém. 1 Např. při každém čtení algoritmem s nedeterministickým dělením dat by bylo potřeba vyzvednout události na dílčích přenosech, přečíst hlavičky přijatých bloků, naplánovat jejich příjem a obsloužit případné zprávy od protistrany. Teprve pak by mohla operace pokračovat. 2 Sledování událostí na souborových deskriptorech lze zajistit nastavením F SETSIG pomocí fcntl(), časové události lze plánovat voláním alarm().

2.3 Architektura systému 20 Poněvadž první zmíněný přístup je pro implementaci v uživatelském prostoru poměrně problematický 3, byl zvolen způsob, kdy se protokol provádí v samostatném vlákně. Aby byly výhody asynchronního přístupu maximálně využity, budeme navíc klást na kód projektu tyto požadavky: Kód provádějící protokol smí uskutečňovat jen taková blokující volání, která čekají na všechny události relevantní pro daný stav instance protokolu. Kód sdílené knihovny musí být časově i paměťově nenáročný. Blokovat smí ve dvou případech. Jednak záměrně, pokud to vyžaduje sémantika prováděné operace, např. paccept() při čekání na spojení. Jednak při potřebě komunikace typu požadavek/odpověď s vláknem, v němž je prováděn protokol předchozí nárok na kód provádějící protokol zaručuje rychlou odezvu. 2.3 Architektura systému Základní koncepci navrženého systému psock zachycuje obr. 2.1. Klíčovou roli hrají dvě komponenty: Vlákno protokolu (Protocol Thread, Protocol Space) je program realizující chod protokolu. Zejména reaguje na události na deskriptorech dílčích přenosů, požadavky uživatele, požadavky z Library Space, zprávy protistrany a časové události. Library Space je kód využívající služeb vlákna protokolu; zahrnuje jednak uživatelský program, jednak implementaci sdílené knihovny nazvané psock-mt 4. Knihovnu volá uživatel prostřednictvím jejího API, ta provádí potřebné úkony včetně vlastní komunikace s vláknem protokolu. Knihovna plní i další úlohu snaží se vytvořit obálky (wrappery) některých systémových funkcí tak, aby bylo možné existující síťové programy upravit pro využití psock s co nejmenšími zásahy. Pod pojmem Library Space se bude nadále rozumět především implementace sdílené knihovny psock-mt. 2.3.1 Komunikace s vláknem protokolu Vlákno protokolu a aplikační program spolu musí komunikovat. Pro vzájemnou komunikaci Library Space a Protocol Space definujeme komunikační rozhraní, dále označované 3 Jedním z důvodů je nemožnost koexistence s obsluhami signálů, které definuje uživatel nebo které používají některá knihovní volání, např. sleep(). 4 psock multithreaded.

2.3 Architektura systému 21 Library Space User API Protocol Thread Association Association Distribution Distribution Dispatching Dispatching Scheduling Scheduling (7) (8) (6) (9) (10) Control Control Engine Engine (5) (4) Dispatching Dispatching Execution Execution (1) (2) (3) Operating System Operating System (allocated (allocated control sockets) control sockets) Operating Operating System System (allocated (allocated data sockets) data sockets) Obrázek 2.1: Architektura systému psock PSCIF 5. Toto rozhraní je pro větší flexibilitu návrhu definováno obecně, bez předepsané implementace. Ve verzi psock běžící v rámci jedné stanice může být realizováno jako sdílená paměť, unixový soket, fronta zpráv; v případné pozdější distribuované verzi psock může jít o UDP nebo TCP soket či volání knihovny MPI 6. 2.3.2 Sdílení soketů dílčích přenosů Pro minimalizaci komunikační režie lze využít faktu, že kontexty vlákna protokolu a Library Space sdílí souborové deskriptory. Bude-li korektně vyřešena synchronizace a bude-li kód Library Space vědět, kdy a jakým způsobem, z kterých dílčích přenosů a v jakém pořadí má přijímat data, může vyřizovat uživatelské požadavky na příjem dat a tato umisťovat přímo do bufferu poskytnutého uživatelem. Analogicky, bude-li Library Space 5 Parallel Socket Controller Interface. 6 Message Passing Interface, http://www-unix.mcs.anl.gov/mpi/.

2.3 Architektura systému 22 vědět, které dílčí přenosy použít k odesílání a jak, může přímo odesílat uživatelská data bez nutnosti použití pomocného bufferu. Úloha vlákna protokolu pak bude spočívat ve sledování událostí na soketech, zpracování řídicích informací a předávání instrukcí Library Space. Stejný přístup lze aplikovat i v případě, že je možné použít duplikované deskriptory tedy takové, které reprezentují tentýž soket. Toho lze využít pro zajištění dědění paralelního soketu při volání fork(). Princip oddělení datového a řídícího přístupu k dílčím přenosům lze dále uplatnit i při pozdějším rozšíření psock na distribuovanou verzi. 2.3.3 Rozvrh paralelního přenosu Sdílení soketů dílčích přenosů umožňuje eliminovat kopírování dat mezi Library Space a vláknem protokolu. Aby byl Library Space schopen samostatně provádět příjem a odesílání dat, udržuje pro každý logický přenos datovou strukturu rozvrh, obsahující instrukce, jak má tyto činnosti provádět (které dílčí přenosy použít, kolik dat po nich poslat atd.). Tabulka 2.1 zachycuje ukázku, jak může vypadat rozvrh pro tři dílčí přenosy. Rozvrh obsahuje nezávislé pozice pro čtení a pro zápis. Každá pozice obsahuje identifikátor dílčího přenosu ( kanonický index ) a délku bloku k přenosu. 7 Dále si knihovna pamatuje pozice v rozvrhu pro čtení i pro zápis. Má-li provést operaci, pro niž není aktuální pozice v rozvrhu vyplněna, musí počkat, až ji obdrží od vlákna protokolu. 8 Pozice obou rozvrhů jsou využívány cyklicky. Pozice v rozvrhu 0 1 2 Kanonický index dílčího přenosu; délka bloku čtení 2; 1448 0; 1448 Kanonický index dílčího přenosu; délka bloku zápis 0; 1448 1; 1448 Pozice v rozvrhu pro čtení 0 Pozice v rozvrhu pro zápis 1 Tabulka 2.1: Příklad rozvrhu paralelního přenosu Protocol Space potřebuje k tvorbě záznamů (instrukcí) přijímacího a vysílacího rozvrhu zejména následující podklady: události na soketech dílčích přenosů, hlavičky datových bloků z dílčích přenosů, notifikace o provedeném příjmu/odeslání bloku a jeho výsledku. 7 Ve skutečné implementaci obsahuje i další informace. 8 V případě neblokujících volání vrátí chybu.

2.4 Řídicí komunikace s protistranou 23 Dostupnost prvních dvou uvedených je zajištěna sdílením souborových deskriptorů, třetí podklad zajišťuje rozhraní PSCIF. Protocol Space má tedy všechny informace potřebné pro tvorbu rozvrhu a do Libary Space je předává opět pomocí PSCIF. 2.4 Řídicí komunikace s protistranou Kromě přenosu datových bloků dílčími přenosy je také potřeba určitá výměna metainformací, zejména při navazování a ukončování spojení. Pro tento účel je dedikováno tzv. řídící spojení (Control Stream). Kromě přenosu řídících zpráv též slouží k reprezentaci celého paralelního soketu adresa paralelního soketu je ve skutečnosti adresou jeho řídícího soketu. Koncové stanice si vyměňují následující řídící zprávy. HELLO iniciační zpráva, zasílaná ihned po spojení řídícího streamu. Obsahuje: identifikátor protokolu zabraňující špatné interpretaci náhodného spojení s jiným protokolem, verzi psock, která se skládá ze trojice: major a minor verze, patchlevel. Aby stanice mohly komunikovat, musí se major a minor verze shodovat. doporučený n rcmd a maximální n max počet dílčích přenosů, identifikátor ovladače paralelního přenosu (viz sekce 3.2.3 na str. 35), prioritu požadovaného ovladače paralelního přenosu. Na zprávu HELLO stanice neodpovídají, neboť obě strany jsou schopny určit potřebné parametry počet dílčích přenosů a ovladač ihned po jejím přijetí. Počet dílčích přenosů n se vypočte jako n = min(max(n rcmd,1, n rcmd,2 ), n max,1, n max,2 ). (2.1) Ovladač se vybírá na základě oznámených priorit; jsou-li stejné, upřednostní se navazující strana. STREAM ANNOUNCE touto zprávou se druhé straně oznamují informace o dostupných datových soketech: dostupný mód soketu (aktivní, pasivní, oba), adresa, na níž bude datový soket naslouchat, resp. z které se bude připojovat, identifikátor tzv. svazku přenosů rezervován pro pozdější využití; bude sloužit k ovlivnění způsobu, jakým se mají dílčí přenosy sdružovat, identifikátor trasy rezervován pro pozdější využití.

2.5 Životní cyklus paralelního spojení 24 Po přijetí zprávy se vypočte párování soketů. Není-li dosažen potřebný počet dvojic, lze seznam nabízených soketů upravit a poslat zprávu znovu. Poznámka 2.1 Zprávy HELLO a STREAM ANNOUNCE nepoužívají systém dotaz/odpověď, jak je zvykem v modelu klient/server. Využívá se plného duplexu a zprávy jsou posílány proti sobě (viz též obr. 2.3). Odpověď se posílá pouze v případě chyby. Postup má za cíl zkrátit dobu navazování spojení. SHUTDOWN oznámení o finalizaci paralelního přenosu. Formálně se vyskytuje ve dvou variantách žádost a odpověď. Obsah zprávy je určen ovladačem paralelního přenosu, typicky je to číslo posledního odeslaného bloku. Ukončování přenosu zpravidla probíhá tak, že jej jedna strana iniciuje žádostí SHUTDOWN a druhá zareaguje odpovědí SHUTDOWN. Stanice ale musí počítat i se situací, kdy dojde k současnému vyslání žádostí SHUTDOWN. Přesný formát zpráv se nachází v souboru src/include/net/psock/psockmsg.h v implementaci projektu. 2.5 Životní cyklus paralelního spojení Dosud byla diskutována především činnost při přenosu dat. Nicméně než je možné přenos zahájit, musí paralelní soket projít několika iniciačními fázemi. Stejně tak po uzavření je potřeba provést finalizaci. Vývoj paralelního spojení s vybranou částí přechodů měnících stav je zachycen na obr. 2.2. Stav paralelního spojení a další data podstatná pro paralelní přenos je udržován v datové struktuře PCB Parallel Stream Transmission Control Block, přesnou definici uvádí sekce 3.1 na str. 31. Vysvětlení významu znázorněných stavů přináší následující část. 2.5.1 Stavy paralelního spojení CLOSED je iniciální a finální stav paralelního soketu. Z hlediska komunikačního protokolu jde o fiktivní stav (podobně jako v definici TCP [14]). LISTEN je stav vznikající při pasivním otevřením soketu. Řídící soket je též ve stavu LISTEN a čeká na příchozí spojení. Po jeho příchodu se vytvoří nový PCB a od PCB naslouchajícího paralelního soketu zdědí většinu vlastností. Pomocí spojeného řídícího soketu je protistraně zaslána zpráva HELLO a nový PCB přechází do stavu HELLO WAIT.

2.5 Životní cyklus paralelního spojení 25 CONNECTING vzniká aktivním otevřením paralelního soketu, s přechodem do tohoto stavu se iniciuje navazování řídícího spojení s protistranou. Po navázání je zaslána zpráva HELLO a PCB přechází do stavu HELLO WAIT. HELLO WAIT je stav, v němž se čeká na přijetí zprávy HELLO od protistrany. Po přijetí HELLO je určen počet spojení pro dílčí přenosy dle vztahu (2.1) a je vybrán ovladač paralelního spojení. Poté obě strany vyhradí potřebný počet adres koncových bodů 9 a oznámí je protistraně pomocí zprávy STREAM ANNOUNCE. S odesláním této zprávy paralelní soket přechází do stavu STREAM ANNOUNCE WAIT. STREAM ANNOUNCE WAIT soket čeká na zprávu STREAM ANNOUNCE, viz též sekce 2.4. Po úspěšném výpočtu párování soketů se přechází do stavu ESTAB- LISHING. ESTABLISHING v této fázi se navazují spojení mezi sokety dílčích přenosů. Navazující strana se připojuje na adresy oznámené naslouchající stranou zprávou STREAM ANNOUNCE; naslouchající strana dovolí spojení pouze z adres, které byly oznámeny ve zprávě STREAM ANNOUNCE její protistrany. S navázáním posledního dílčího spojení paralelní soket přechází do stavu ESTABLISHED. ESTABLISHED je stav, v němž je paralelní soket většinu času své existence. Paralelní soket tuto fázi opouští buď na žádost protistrany a po jejím potvrzení přechází do SHUTDOWN RECEIVED, nebo na žádost uživatele, kdy po zaslání zprávy SHUTDOWN protistraně přechází do SHUTDOWN SENT. V obou případech stanice zahájí vyprazdňování zbylých dat v bufferech. Zpracování těchto dat určuje ovladač paralelního přenosu. SHUTDOWN SENT je stav, kdy finalizace paralelního spojení byla zahájena uživatelem, ale ještě nebyla potvrzena protistranou, a přenos dat nebyl ukončen. SHUTDOWN RECEIVED je stav, kdy finalizace paralelního spojení byla oznámena protistranou, ale ne uživatelem, a přenos dat nebyl ukončen. SHUTDOWN APPROVED je stav, kdy finalizace paralelního spojení byla oznámena uživatelem i protistranou, nicméně přenos dat nebyl zcela ukončen. SHUTDOWN WAIT je stav, kdy se s uvolněním prostředků paralelního přenosu čeká pouze na oznámení od uživatele. SHUTDOWN ACK WAIT je stav, kdy se s uvolněním prostředků paralelního přenosu čeká pouze na oznámení od protistrany. 9 Tedy dvojic IP adresa, port.

2.5 Životní cyklus paralelního spojení 26 Poznámka 2.2 Tzv. half open spojení, známá z TCP, nejsou v současné verzi návrhu zahrnuta. Nicméně bude-li tato funkcionalita v budoucnosti potřebná, změny si vyžádají jen malé úpravy. Lepší pohled na časovou souvztažnost událostí vývoje paralelního soketu přináší obrázky 2.3 a 2.4. Zprávy protokolu psock jsou na obrázcích zobrazeny tlustou čarou, významné pakety protokolu TCP jsou značeny tence. Zprávy protokolu psock se předávají spolehlivým kanálem (proto nejsou vyznačena potvrzení protokolu nižší vrstvy). V obrázku 2.3 stojí za zmínku určení počtu dílčích přenosů ze zpráv HELLO(n rcmd, n max ) dle vztahu (2.1). K obrázku 2.4 poznamenejme, že přesný průběh ukončování spojení závisí na vzájemném pořadí následujících tří událostí: ukončení spojení na požadavek uživatele, ukončení na požadavek protistrany a dokončení komunikace na dílčích přenosech to ostatně plyne z diagramu na obr. 2.2. Obrázek zachycuje jednu z možností (datové pakety dílčích přenosů jsou pro přehlednost vynechány).

2.5 Životní cyklus paralelního spojení 27 CONNECTING passive open LISTEN active open / connect control stream CLOSED control stream connected / send hello HELLO_WAIT accept on control stream / duplicate pcb, send hello recv hello / send stream announce STREAM_ANNOUNCE_WAIT recv stream announce ESTABLISHING establishment of a pstream establishment of the last pstream recv shutdown / send ack ESTABLISHED shutdown / send shutdown recv shutdown ack SHUTDOWN_SENT recv shutdown / (ptransfer driver specific) flush_end SHUTDOWN_RECEIVED shutdown SHUTDOWN_APPROVED flush_end flush_end SHUTDOWN_WAIT shutdown recv shutdown ack SHUTDOWN_ACK_WAIT CLOSED recv shutdown / (ptransfer driver specific) Obrázek 2.2: Přechodový diagram paralelního soketu (zjednodušeno)

2.5 Životní cyklus paralelního spojení 28 CLOSED Control stream SYN CONNECTING Control stream SYN+ACK LISTEN Control stream ACK HELLO(2,4) HELLO(3,5) HELLO WAIT HELLO WAIT STREAM ANNOUNCE STREAM ANNOUNCE WAIT STREAM ANNOUNCE pstream 1 SYN STREAM ANNOUNCE WAIT pstream 2 SYN pstream 3 SYN pstream 1 SYN+ACK ESTABLISHING pstream 2 SYN+ACK pstream 1 ACK pstream 3 SYN+ACK ESTABLISHING pstream 2 ACK pstream 3 ACK ESTABLISHED ESTABLISHED Obrázek 2.3: Navazování paralelního spojení

2.5 Životní cyklus paralelního spojení 29 ESTABLISHED Shutdown by user SHUTDOWN REQUEST ESTABLISHED SHUTDOWN SEND SHUTDOWN APPROVED Flushing pstream 1 Flushing pstream 2 Flushing pstream 3 pstream 1 FIN pstream 3 FIN pstream 2 FIN SHUTDOWN REPLY pstream 2 FIN pstream 1 FIN pstream 3 FIN Flushing pstream 1 Flushing pstream 2 Flushing pstream 3 SHUTDOWN RECIEVED CLOSED Control stream FIN SHUTDOWN WAIT Shutdown by user CLOSED Obrázek 2.4: Ukončování paralelního spojení

30 Kapitola 3 Implementace Paralelizační systém je implementován v uživatelském prostoru jako sdílená knihovna, která si pro svoji činnost vytváří pomocná výpočetní vlákna. Programátorské rozhraní (viz příloha B.1) se velmi podobá standardním voláním specifikací BSD a POSIX, aby bylo možné snadno zavést možnost používání paralelních přenosů do existujících aplikací. 3.1 Pojmy a struktury Tato sekce popisuje klíčové pojmy, vztahy a datové struktury použité v implementaci psock a jejím dále uvedeném popisu. Výčty uvádí jen nejdůležitější položky, podrobnější informace lze dohledat ve vygenerované dokumentaci zdrojových kódů. Protocol Space, Library Space viz sekce 2.3. pstream je dílčí přenos představovaný TCP spojením. Řídící přenos je TCP spojení určené k přenosu řídících zpráv pro paralelní přenos. Instance protokolu je představována běžícím stavovým automatem; odpovídá jí běžící vlákno protokolu. Zatímco u síťových technologií implementovaných v jádru monolitických operačních systémů je obvyklá jedna instance protokolu v rámci stanice, v současné implementaci v uživatelském prostoru připadá jedna instance protokolu na jeden paralelní přenos. Důvodem je zejména lepší spravovatelnost. Ovladač paralelního přenosu ptransfer driver je sada metod realizujících konkrétní algoritmus rozdělování dat do dílčích přenosů a jejich zpětné rekonstrukce (dispatching). Ovladač má dvě komplementární části: Ovladač paralelního přenosu ve vlákně protokolu ptransfer pdrv je na obrázku 2.1 reprezentován komponentou Dispatching Scheduling. Jeho vstupem jsou zejména zprávy s výsledky provedení instrukcí z Library Space (5) a události na dílčích přenosech (2).

3.1 Pojmy a struktury 31 Ovladač paralelního přenosu v Library Space ptransfer cdrv se používá při obsluze uživatelských požadavků. Provádí přenosové instrukce (viz část 2.3.3) a reaguje na výsledek jejich provedení. PCB (Parallel Stream Transmission Control Block) je datová struktura v Protocol Space sdružující informace o paralelním přenosu. Nese s sebou zejména tyto informace: referenci na instanci protokolu, do níž PCB patří, komunikační rozhraní PSCIF, umožňující obousměrnou komunikaci s Library Space, souborový deskriptor řídícího přenosu, datové struktury pro zpracování zpráv na řídícím přenosu, stav paralelního přenosu, hodnoty soketových nastavení (přístupné voláním setpsockopt() v úrovni SOL PSOCK), hodnoty platné jen pro PCB ve stavu LISTEN: backlog maximální počet příchozích spojení čekajících na převzetí uživatelem, seznam čekajících spojení, hodnoty platné pro PCB ve stavu CONNECTING a pozdějších: datové struktury odpovídající jednotlivým dílčím přenosům. Obsahují vždy deskriptor příslušného soketu, zbytek definuje použitý ovladač paralelního přenosu, vlastní ovladač paralelního přenosu, data algoritmu paralelního přenosu (význam dán použitým ovladačem paralelního přenosu), řadu dalších pomocných atributů. struct psock je datová struktura v Library Space obsahující informace, jež je potřeba uchovávat mezi jednotlivými uživatelskými voláními knihovny. Obsahuje zejména tato data: komunikační rozhraní PSCIF umožňující obousměrnou komunikaci s vláknem protokolu, odkaz na ovladač paralelního přenosu v Library Space, hodnoty platné jen pro stav LISTEN: seznam struktur psock odpovídajících příchozím spojením; při volání funkce paccept() je vytvořen deskriptor příchozího spojení a je předán uživateli,

3.2 Vlákno protokolu 32 struktury platné pro spojený paralelní soket: rozvrh instrukcí pro odesílání dat, rozvrh instrukcí pro příjem dat. 3.2 Vlákno protokolu Vztahy objektů v Protocol Space jsou znázorněny na obr. 3.1. Library Space (cut) PSCIF communication driver 2 Protocol Thread(s) Protocol instance, running state machine ptransfer driver B (Protocol space part) Control stream and control block psock s PSCIF interface PSCIF communication driver 1 PCB s PSCIF interface PCB pstream 1 pstream 2 pstream n psock s PSCIF interface Protocol instance, running state machine PCB s PSCIF interface PCB Control stream and control block pstream 1 pstream 2 pstream n ptransfer driver A (Protocol space part) Obrázek 3.1: Vztahy struktur v Protocol Space V hlavní smyčce vlákna protokolu se sledují obsluhované souborové deskriptory a časové události pomocí volání poll(). Obsluhovanými sokety jsou: řídící přenos, dílčí datové přenosy a rozhraní PSCIF pro komunikaci s Library Space, které je v současné verzi implementováno jako unixový soket. Po návratu z volání poll() jsou na základě jeho výsledků generovány příslušné události; ty jsou pak předány ke zpracování stavovému automatu. 3.2.1 Události Událost je identifikována dvěma čísly typem a podtypem. Události s sebou mohou nést datový argument.

3.2 Vlákno protokolu 33 Typy a podtypy událostí jsou: PSKEV T STREAM událost týkající se přenosů, patří sem: PSKEV DATA STREAMS POLL výskyt události na datových přenosech. Ve stavu ESTABLISHED a při zavírání spojení předáváno ke zpracování ovladači ptransfer pdrv. PSKEV CTL STREAM POLL vyskytla se událost na řídícím spojení. Využívá se při navazování spojení a pro obsluhu řídících zpráv. PSKEV DATA STREAMS ESTABLISHMENT událost generovaná ve stavu ESTABLISHING při spojení všech dílčích přenosů. PSKEV DATA STREAM HANGUP generováno při chybě na datovém přenosu. PSKEV CTL STREAM HANGUP generováno při chybě na řídícím přenosu. PSKEV DATA STREAMS FLUSH END generováno v závěrečné fázi života paralelního soketu při dokončení přenosu zbývajících dat. PSKEV T LIB2PROTO zprávy posílané vláknu protokolu z Library Space. Číslo (kód) zprávy se používá přímo jako podtyp události. Argumentem události je reference na přijatou zprávu. Definovány jsou tyto zprávy: PSKEV LIB2PROTO RECV INSTR RES oznámení výsledku provedení instrukce příjmu z pstreamu, PSKEV LIB2PROTO SEND INSTR RES oznámení výsledku provedení instrukce odeslání na pstream, PSKEV LIB2PROTO TRANSFER požadavek na datový přenos mezi knihovnou a protokolem, využívá se zřídka, 1 PSKEV LIB2PROTO PSOCKCTL zahrnuje různé požadavky na vlákno protokolu, mezi tyto požadavky patří mj. nastavení a dotazy na vlastnosti soketu nebo protokolu v rámci volání setpsockopt() a getpsockopt(), PSKEV LIB2PROTO BIND pojmenování soketu, aplikuje se na řídící stream, PSKEV LIB2PROTO PASSIVE OPEN příkaz k přechodu PCB do režimu LISTEN, PSKEV LIB2PROTO ACTIVE OPEN příkaz ke spojení se vzdáleným systémem, 1 V současné verzi se tyto přenosy nepoužívají. Význam budou mít zejména při rekonfiguraci dílčích přenosů.

3.2 Vlákno protokolu 34 PSKEV LIB2PROTO SHUTDOWN příkaz ke korektnímu ukončení protokolu, PSKEV LIB2PROTO ABORT násilné zrušení paralelního soketu. PSKEV T CTLMSG řídící zprávy od vzdáleného systému. Podtyp události je odvozen z kódu zprávy jako 2(msg code 1) + (is reply? 1 : 0). Argumentem události je reference na přijatou zprávu. 3.2.2 Reakce na událost Na základě stavu PCB, typu a podtypu události se určí obslužná funkce. 2 Popis činnosti obslužných funkcí přesahuje rámec tohoto dokumentu; v případě zájmu lze informace dohledat ve zdrojových kódech, startovním místem je soubor src/net/psock/ sm funcs.inc.h. Po provedení obslužné funkce a případném obsloužení výjimečných stavů se pokračuje další iterací hlavní smyčky. Zprávy zasílané do Library Space Zprávy zasílané vláknem protokolu do Library Space představují buď reakce na přímý požadavek Library Space, nebo asynchronní oznámení, která jsou generována na základě jiných událostí. Počítá se s tím, že Library Space asynchronní zprávy zpracuje až v momentě uživatelského volání knihovny neočekává se okamžité zpracování a počet asynchronních zpráv je omezený. Asynchronních zpráv je jen několik druhů, přičemž většina je tvořena instrukcemi pro rozvrh paralelního přenosu. Jelikož rozvrh má danou velikost, je právě ta omezením počtu asynchronně zaslaných instrukcí. Předávání instrukcí pro paralelní rozvrh probíhá následujícím způsobem: jakmile vlákno protokolu zjistí, že je možné naplánovat příjem, resp. vyslání nějakého bloku z/do některého dílčího přenosu, odešle do Library Space instrukci PSKEV PROTO2LIB - RECV INSTR, resp. PSKEV PROTO2LIB SEND INSTR a přestane se zajímat o připravenost daného dílčího přenosu pro čtení, resp. zápis. Až Library Space instrukci vyzvedne, zařadí ji na příslušné místo svého rozvrhu. Teprve po jejím provedení zasílá zprávu PSKEV LIB2PROTO RECV INSTR RES, resp. PSKEV LIB2PROTO SEND INSTR - RES spolu s výsledkem. Poté může vlákno protokolu obnovit sledování připravenosti daného dílčího přenosu pro čtení, resp. zápis. Poznamenejme, že plánování rozvrhu paralelního přenosu nemusí nutně probíhat uvedeným způsobem. V případě jednoduchého algoritmu přenosu, jako je round-robin, by byl výše uvedený postup zbytečně těžkopádný. Proto instrukce mohou být generovány 2 Kompletní tabulka přechodů je v souborech doc/statetable.* ve stromu projektu. Optimalizovaná tabulka obslužných funkcí v jazyce C je generována programem scripts/gen state table.