Virtlab:Protokoly/Rezervační server
Z VirtlabWiki
(Rozdíly mezi verzemi)
Verze z 21:13, 2. 1. 2007 Hra196 (Diskuse | příspěvky) (zmena syntaxe parametru time a id) ← Předchozí porovnání |
Verze z 11:37, 10. 1. 2007 Hra196 (Diskuse | příspěvky) (Stránka Virtlab:DistrProtokolRezervServer přemístěna na stránku Virtlab:Rezervační server – komunikační protokol: Konečně srozumitelný název ;)) Následující porovnání → |
Verze z 11:37, 10. 1. 2007
Protokol rezervačního serveru
První návrh:
- Dotaz na prvky lokality daného rezervačního serveru (parametry: ID dotazující se lokality - filtrace podle ní, časový úsek - spec. případ bez udání času vrátí všechny potenciálně zapůjčitelné prvky pro žádající lokalitu)
- Dotaz na všechny prvky systému (zevnitř lokality lokálnímu rezervačními serveru, dotazy zvnějšku lokality budou filtrovány aplikací serveru (nepřicházejí z privátní zdrojové adresy)
- slouží jako proxy, zeptá se všech rezervačních serverů jiných lokalit (zprávou dotaz na prvky lokality)
- může být speciálním případen zprávy pro dotaz na prvky lokality s nastaveným příznakem žádosti o rekurzi.
- Zadost o rezervaci - DOPRACOVAT PARAMETRY A MOZNE ODPOVEDI NA ZPRAVU
- Zrušení rezervace podle globálního čísla rezervace (u sebe nebo rekurzivně u všech, rekurze přijímána jen při poždavku zevnitř lokality)
- Výpis rezervací – výpis rezervační tabulky (lokálního rezervačního serveru nebo rekurzivně, ale v rekurzivním případě vrátí jen rezervace rezervace z tázající se lokality)
ID rezervace – bude vymýšlet rezervující lokalita (název lokality + sekvenční číslo). Bude sloužit i k možnosti zruseni rezervace
Při komunikaci mezi rezervačními servery uvádět jako parametr ID tázající se lokality + vymyslet systém autentizace, aby se ID tázající lokality nedalo podvrhnout.
Lze počítat s tím, že komunikace půjde IPSec tunelem.
Distribuovaná rezervace prvků je distribuovanou transakcí, vymyslet 2-fázový commit, včetně podpory rollbacku od timeoutu při neaktivitě rezervačního klienta. Rezerv. server obsluhuje více spojení najednou, promyslet, zda nevznikají potenciální deadlocky.
Administrátorské CLI rezervačního serveru - navrh
- Výpis všech rezervací (dle časového intervalu od-do)
- Smazání záznamů o již proběhnuvších rezervacích
- Smazání budoucí rezervace
Komunikační protokol (návrh Tomáše Hrabálka)
Výpis ze souboru reserv/doc/popis.txt:
Popis komunikačního protokolu ============================= - pres TCP spojeni - textove prikazy, oddelene <LF>, <CR> je ignorovano - case insensitive - prvni radek urcuje prikaz, dalsi jeho argumenty - na poradi argumentu nezalezi - za nazvem argumentu je dvojtecka, za kterou ihned nasleduji jeho parametry - whitespace (<tab>, mezery) nejsou povoleny, slouzi jako oddelovace parametru pro arg. - odeslani prazdneho radku, jen <LF>, potvrdi, ze vsechny argumenty byly odeslany - spojeni ukonceno vzdy na zadost klienta - pri odpovedi je na prvnim radku kod odpovedi, mezera a za ni popis odpovedi, pote jsou poslana textova data - server po komunikace neukoncuje spojeni, pouze po urcitem timeoutu Zjisteni obecne nabidky RS -------------------------- Prikaz: "GET-OFFER\n" Argument (povinny): "FOR: +'jednoznacny nazev lokality'\n" napr. "FOR:vsb_ostrava\n" Odpoved: XML soubor s prefiltrovanou nabidkou fyzickych zarizeni pro danou lokalitu Zjisteni nabidky celeho distribuovaneho RS ----------------------------------------- Stejne jako obecne zjisteni "GET-OFFER" Argument (povinny): DISTRIB Parametr: "YES", "DISTRIB:YES" Odpoved: XML soubor s prefiltrovanou nabidkou fyzickych zarizeni pro cely distribuovany RS Zjisteni nabidky v danem case (Co je volne?) -------------------------------------------- Argument (povinny): "TIME:FROM{YYYY-MM-DD HH:MM}TO{YYYY-MM-DD HH:MM}\n" napr. "TIME:FROM{2006-12-24 09:45}TO{2007-01-01 15:14}\n" Odpoved: XML soubor s nabidkou vsech fyzickych zarizeni lokalne nebo v celem Distr VL pro danou lokalitu, podle argumentu (DISTRIB) Potvrzeni rezervace ------------------- - Rezervace je potvrzovana <<dvojtym commit>>, nejprve volanim prikazu "RESERVE\n" a pote "COMMIT" - Zavolani "RESERVE" na vzdaleny rezervacni server znamena, ze si server dany cas zablokuje, ostatnim ho neposkytne a ceka (dany cas) na "COMMIT". - Druhy COMMIT je zavolan, byl-li prvni u vsech serveru uspesny - Nebyl-li uspesny, volame prikaz ROLLBACK - Nastane-li timeout, vola se ROLLBACK automaticky - Povinnym argumentem je vygenerovane globalni Reservation id, ktere je slozene z lokality a mistniho cisla id: "ID:<LocalID>@<lokalita>" - Povinne je rovnez uvest cas ve stejnem formatu jako u zjistovani nabidky - Jako dalsi argumenty COMMIT jsou ID sitovych prvku dane lokace (kazde jako zvlastni argument) - Argumet: DEVICE:id_zarizeni\n - Odpoved: 200 ACCEPTED<lf> ...kladna odpoved 400 REFUSED<lf> ...zaporna odpoved Smazani rezervace ----------------- - Prikaz "CANCEL" - Povinny argument "ID:<lokalita> <id>" - Argument "DISTRIB:YES" pro distribuovanou verzi - Odpoved "210 Cancelled" operace provedena "410 Bad ID" zadne takove ID neexistuje
Priklad ------- User->Local RS -> GET-OFFER<lf> FOR:su_karvina<lf> DISTRIB:yes<lf> <lf> <- 200 OK <?XML ..... > end of the connection -> GET-OFFER<lf> FOR:su_karvina<lf> DISTRIB:yes<lf> TIME:FROM{2007-01-18 10:00}TO{2007-01-18 11:00}<lf> <lf> <- 200 OK <? XML .... > end of the connection -> RESERVE<lf> FOR:su_karvina<lf> ID:14@su_karvina TIME:FROM{2007-01-18 10:00}TO{2007-01-18 11:00}<lf> DEVICE:r1 DEVICE:r5 DEVICE:sw2 <lf> <- 200 ACCEPTED end of the connection -> COMMIT<lf> <- 200 ACCEPTED end of the connection