Jan Syrovátka

 Nemožnost rychlého vývoje a nasazování nových protokolů a služeb  Model Internetu dovoluje pouze limitované zabezpečení  Mobilní stanice se chovají staticky, neboť není podporována mobilita v síti  V porovnání s aktivními sítěmi, vývoj s luž e b jako adaptivní překódování dat je příliš náročný

 Vznik termínu  „DARPA“ – Defense Advanced Research Project Agency (1996)  Principy na nichž aktivní sítě stojí  Vytvoření konceptu architektury, jež dovolí snadno vyvinout a nasadit nové služby  Přizpůsobení sítě potřebám aplikací  Bezpečnost už od základu

 Přerozdělování zátěže pro distribuované výpočty  Řešeno v pracích ing. Koutného  Vznikla implementace aktivních sítí nazvaná Grade 32  Sítě s dynamickou topologií, např. satelitní  IIP (Intelligent Internet Protokol) Capsule IIP obsahuje 2 reference na kód místo 1  Vývoj nových protokolů  Protokol na vytváření směrovacích tabulek

 Multicasting  Řešení problému zajištění multicastového provozu proti ztrátě paketů.  Kvalita služeb  Nezbytná pro přenos dat v reálném čase (např. videokonference)  Teoretický i praktický problém  Data projdou sítí s požadovanou kvalitou služby, je-li možné. Pokud ne pak s nejlepší jakou síť dovolí

 Data v aktivních sítích  Přenášené jednotky – Capsule, spojena s programy  Lepší interakce než u klasických sítí - statické datové formáty  Princip funkčnosti  Pro příchozí data spouštěny programy  Programy tvoří protokoly a služby  Snadné nasazení nových protokolů a služeb  Spojení mezi servery pro komunikaci na základě podnětu

 Jednotka přenášených dat (paket tradiční sítě )  Slouží k přenosu dat a programů  Obsah Capsule  Aktivní kód Dostupnost kódu na uzlu, z něhož přenos začíná Ostatní uzly pak mohou aktivní kód získat Kód pak lze vykonávat, distribuovat  Formát se liší dle implementace

 Grade 32  Metody přerozdělování zátěže distribuovaných aplikací  Smart Active Node (SAN)  Nástupce za Grade 32  Kombinuje navíc některé vlastností ANTS, PLANet

 Programovací jazyk – JAVA  Objektově orientovaný přístup, přenositelnost, silný typový systém  Capsule ID - jednoznačný identifikátor capsule Dest, SRC – cílovou, zdrojová adresu uzlu IDA - identifikátor aplikace, která capsuli vytvořila IDC - identifikuje kód capsule, který se má na serveru spustit Hop limit – max. počet uzlů, přes které může capsule projít Data - uživatelská data, zpracována samotným programem capsule nebo je capsule může předat aplikaci

 S rostoucí flexibilitou roste potřeba bezpečností  Neúmyslné či záměrné chyby v uživatelských programech pro směrovače  Možná nebezpečí  Nedostupnost zdroje - přetížení zahlcováním sítě velkým množstvím dat nebo spotřebou velkého množství zdrojů  Poškození – dat, dalších programů, či jiných směrovačů  Krádež - zcizí soukromé informace ze směrovače (přenášená osobní data, databáze uživatelů a šifrovacích klíčů,...).

 Zpočátku Bean Shell  Dočasné řešení  Bezpečnostní problémy – pro aplikaci nevhodný  Vlastní interpretace kódu  Interpret „Java – in – Java“  Lépe kontrolovatelná exekuce kódu  Navíc u Bean Shellu některé další problémy s vykonáváním (typované kolekce apod.)

 Vytvořena „Stand alone“ verze  Překlad zařizuje standardní kompilátor Javy  Vlastní interpretace bytecodu  Integrace se zbytkem projektu  Potřeba nevzdávat se kontroly nad interpretováním v žádném okamžiku  Vytvoření upravené verze interpretu (interpretuje se vše)

 Některé výhody  Navázání na bezpečnostní monitor Server je vždy „o krok napřed“ před potencionálně nebezpečným kódem  Vlastní plánování, možnost rezervovat výpočetní kapacitu pro capsule a aktivní aplikace  Možnost implementace fibres, ne pouze threads  Možnost implementace vlastních synchronizačních primitiv jako je např.: Rendez-vous známé z Ady Podmínkové proměnné POSIXu WaitForMultipleObjectsEx z WinAPI

 Perspektivní koncept  Rozvíjený směr výzkumu a vývoje, nikoli realita běžné komunikace  Spousta výhod proti používaným technologiím  Do budoucna  Vytvoření aplikací využívajících stávající implementaci