Virtlab:Protokoly/Rezervační server

Z VirtlabWiki

(Rozdíly mezi verzemi)
Přejít na: navigace, hledání
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
Osobní nástroje