Virtlab:Komponenty/Rozdělení rezervačního a aktivačního serveru
Z VirtlabWiki
| Verze z 13:08, 14. 8. 2007 Bam015 (Diskuse | příspěvky) (popis rozdeleni rsv a act serveru) ← Předchozí porovnání |
Verze z 14:06, 14. 8. 2007 Gry72 (Diskuse | příspěvky) Následující porovnání → |
||
| Řádka 1: | Řádka 1: | ||
| - | Původní rezervační server v sobě obsahoval proces, který zajištoval aktivaci rezervací. Z důvodu větší modularity došlo k oddělení této komponenty a vznikl samostatný aktivační server. Způsob rozdělení a následnou komunikaci mezi servery popisuje obrázek: | + | Původní rezervační server v sobě obsahoval kód spouštěný jako dětský proces, který zajištoval aktivaci virtuálních topologií před začátkem jednotlivých rezervací. Rodičovský proces rezervačního serveru informoval svůj dětský (aktivační) proces o významých událostech pomocí signálů. Z důvodu větší modularity jsme provedli oddělení aktivačního kódu do samostatné komponenty, čímž znikl samostatně spouštěný aktivační server. Komunikace mezi rezervačním a aktivačním serverem nyní probíhá přes TCP. Způsob rozdělení a následnou komunikaci mezi servery popisuje obrázek: |
| + | |||
| [[Image:P8030001.JPG|400px]] | [[Image:P8030001.JPG|400px]] | ||
| - | V podstatě jde o to, že se z původního rezervačního serveru vytvořila identická kopie. | + | |
| - | Oba zdrojové kódy byly následně upraveny tak, že po vytvoření dalšího procesu pomocí příkazu fork(), kde obslužný kód pro hlavní proces (rodič), obstarával funkci rezervačního, zůstal samostatně v rezervačním serveru a obslužný kód pro dětský proces (potomek), je implementován v aktivačním serveru. | + | V případě nějaké změny (nové rezervace, zrušení rezervace) pošle rezervační server pokyn aktivačnímu serveru, aby se podíval do databáze a podle toho si nastavil alarm na čas nejbližší rezervace. Když rezervační server zpracovává novou rezervaci (resp. příkaz ATTACH), přepošle informaci o virtuální topologii požadované pro danou rezervaci aktivačním serveru, který si ji uloží do souboru (<resID>.dat). V případě, že pak nastane čas konkrétní rezervace, spustí aktivační server aktivační skript. |
| - | Na následnou komunikaci (na portu 50002) mezi rezervačním serverem a nově vzniklým aktivačním serverem (v rámci lokality) se využil stejný komunikační protokol, jako mezi rezervačními servery navzájem. Rozdíl je v použitých příkazech, které jsou popsány v [[Virtlab:Aktivační server – komunikační protokol | komunikačním protokolu aktivačního serveru]]. | + | V případě zrušení rezervace posílá rezervační server aktivačnímu serveru jako parametr příkazu '''delresid''' ResID zrušené rezervace, takže už si může vytvořený soubor smazat. |
| - | Princip je takový, že v případě nějaké změny (nové rezervace, zrušení rezervace) pošle rezervační server pokyn aktivačnímu serveru, aby se podíval do databáze a podle toho si nastavil alarm. | + | |
| - | Při nové rezervaci se zároveň pošlou informace o propojení jednotlivých požadovaných zařízeních, které si aktivační server uloží do souboru. V případě, že pak nastane čas konkrétní rezervace je dále zpracovává. | + | Za normálních okolností smaže soubor <resID>.dat aktivační skript po dokončení své činnosti. |
| - | V případě zrušení rezervace, posílá rezervační server aktivačnímu pokyn s identifikátorem '''delresid''' zrušené rezervace, že už si může vytvořený soubor smazat. | + | |
Verze z 14:06, 14. 8. 2007
Původní rezervační server v sobě obsahoval kód spouštěný jako dětský proces, který zajištoval aktivaci virtuálních topologií před začátkem jednotlivých rezervací. Rodičovský proces rezervačního serveru informoval svůj dětský (aktivační) proces o významých událostech pomocí signálů. Z důvodu větší modularity jsme provedli oddělení aktivačního kódu do samostatné komponenty, čímž znikl samostatně spouštěný aktivační server. Komunikace mezi rezervačním a aktivačním serverem nyní probíhá přes TCP. Způsob rozdělení a následnou komunikaci mezi servery popisuje obrázek:
V případě nějaké změny (nové rezervace, zrušení rezervace) pošle rezervační server pokyn aktivačnímu serveru, aby se podíval do databáze a podle toho si nastavil alarm na čas nejbližší rezervace. Když rezervační server zpracovává novou rezervaci (resp. příkaz ATTACH), přepošle informaci o virtuální topologii požadované pro danou rezervaci aktivačním serveru, který si ji uloží do souboru (<resID>.dat). V případě, že pak nastane čas konkrétní rezervace, spustí aktivační server aktivační skript.
V případě zrušení rezervace posílá rezervační server aktivačnímu serveru jako parametr příkazu delresid ResID zrušené rezervace, takže už si může vytvořený soubor smazat.
Za normálních okolností smaže soubor <resID>.dat aktivační skript po dokončení své činnosti.
