[MWy] Ctvrte cviceni pondeli 28. 4. 14:00 SU2

[Martin Decky]

Hezky vecer,

ctvrte cviceni z predmetu Middleware se uskutecni v terminu uvedenem
v predmetu tohoto emailu. Tema bude tentokrat Key-Based Routing.

Budeme pouzivat middleware Chimera 1.2.0, ktery lze stahnout z webu 
http://current.cs.ucsb.edu/projects/chimera/. Z odkazu uvedeneho nize si 
muzete stahnout predprelozenou knihovnu (pro Linux x86), kterou staci 
rozbalit do domovskeho adresare.

http://dsrg.mff.cuni.cz/~ceres/sch/mwy/download/Chimera-1.2.0-bin.tar.gz

Ukazka pouziti slouzi tentokrat zaroven jako zaklad ulohy a muzete si ji 
stahnout z adresy uvedene nize. Makefile je tradicne napsan tak, aby se 
ukazka prelozila s Chimerou nainstalovanou do domovskeho adresare, napr. 
z predpripravene binarky (viz vyse).

http://dsrg.mff.cuni.cz/~ceres/sch/mwy/download/as4.zip

Vzhledem k tomu, ze dokumentace k Chimere je pomerne strucna, opravdu 
Vam velmi vrele doporucujeme, abyste se dukladne seznamili s prikladem 
pouziti, ktery mate k dispozici (a ktery predstavuje take zaklad pro 
ulohu na cviceni). Idealne si vyzkousejte take nejakou lehkou modifikaci 
ukazky, zopakujte zpusob pouziti prekladace GCC, utility make atd.

Situace s dokumentaci je kompenzovana tim, ze Chimera je na rozdil od 
predchozich middleware technologii skutecne velmi jednoducha.

Na konci emailu naleznete predbeznou podobu zadani ulohy. Veskera 
pravidla pro vypracovani zustavaji standardni.


M.D.


===[ Ctvrta uloha z Middleware: Zaklady Key-Based Routingu ]===

---[ Zakladni zadani ]---

      Za uspesne dokonceni zadani behem cviceni jsou 2 body.
      Studenti, kterym se nepodari ulohu dokoncit behem cviceni,
      mohou za jeji uspesne dokonceni jeste tentyz den dostat 1 bod.

Cilem zadani je ziskat zakladni zkusenost s peer-to-peer overlay sitemi
zalozenymi na Key-Based Routingu (Addressing by Content).

Pozadovane znalosti:

   Zadani ulohy popisuje rozsireni jednoducheho chatu, kde si ucastnici
   mohou posilat privatni zpravy, o moznost pripojovani se k takzvanym
   kanalum, ktere distribuuji zpravy zaslane do kanalu vsem pripojenym
   ucastnikum (podobne jako napr. v IRC). Pro pochopeni ulohy neni
   potreba zadna zvlastni znalost.

   Jako technologie posilani zprav je pouzita peer-to-peer overlay
   zalozena na Key-Based Routingu, konkretne implementace Chimera 1.20
   v jazyce C (lze pouzit i C++). Pro implementaci ulohy je potreba
   znalost nasledujicich veci:

    - Zakladni myslenka Key-Based routingu: dorucovani zprav ucastnikum
      na zaklade hashovacich klicu, prace s klici v implementaci Chimera
      (funkce key_makehash, get_key_string, str_to_key, chimera_setkey).

    - Inicializace Chimery, pripojeni ucastniku do site, bootstrap z jiz
      beziciho ucastnika (funkce chimera_init, host_get, chimera_join).

    - Zpusob zasilani zprav: format zpravy (typ, delka, payload),
      registrace typu zprav (chimera_register), asynchronni upcall funkce
      pro prijem zprav a zpracovani dalsich udalosti (chimera_deliver,
      _update, _forward), zasilani zprav (chimera_send).

   K dispozici bude ukazkovy priklad jednoducheho chatu, ktery muze take
   pouzit k implementaci ulohy rozsirenim tohoto prikladu.

Popis ulohy:

   Implementujte jednoduchy chat po siti bez centralniho serveru pomoci
   peer-to-peer middleware Chimera.

   Aplikace musi plnit tyto funkce:

   1. Pri spousteni zada uzivatel jmeno, pod kterym chce na chatu
      vystupovat. Z nej aplikace vytvori hashovaci klic klienta. Uzivatel
      muze take zadat adresu a port stroje, ze ktereho se ma provest
      bootstrap. Po spusteni aplikace inicializuje Chimeru s danym klicem
      (a s pripadnym bootstrapem) a ceka na prikazy uzivatele.

   2. Uzivatel muze prikazem (napr. "msg user message") poslat privatni
      zpravu jinemu uzivateli chatu -- zprava bude adresovana spravnemu
      klientu pomoci hashe jmena prijemce. Aplikace pri prijmu teto
      zpravy overi, zda souhlasi prijemce a v takovem pripade zobrazi
      zpravu uzivateli.

   Pozn.: V ukazkovem priklade jsou body 1 a 2 jiz implementovany.

   3. Uzivatel se muze prikazem (napr. "join #channel") pripojit ke
      zvolenemu kanalu. Aplikace zasle pozadavek na pripojeni klientovi
      pomoci hashe jmena kanalu -- tento klient pak kanal spravuje, tj.
      eviduje pripojene ucastniky a rozesila jim zpravy (viz bod 4).
      Zprava s pozadavkem by tedy mela obsahovat vhodnou identifikaci
      pripojujiciho se klienta.

   4. Uzivatel muze prikazem (napr. "send #channel message) poslat zpravu
      do daneho kanalu pomoci klienta (spravce kanalu), ktery zpravu
      rozesle vsem ucastnikum prihlasenym do daneho kanalu. Klient, ktery
      zpravu posila, nemusi byt sam prihlaseny. Pokud prihlaseny je, je
      mu zprava spravcem kanalu dorucena take.

   5. Uzivatel muze prikazem (napr. "leave #channel") opustit dany kanal.
      Budouci zpravy z tohoto kanalu mu jiz doruceny nebudou.

---[ Rozsirene zadani ]---

      Studenti, kterym se nepodari ulohu dokoncit behem cviceni,
      mohou za uspesne dokonceni jeji rozsirene verze do peti
      dnu dostat 2 body.

Popis ulohy:

   Zakladni zadani predpoklada, ze kanaly jsou pevne svazany s jejich
   spravci. Rozsirte implementaci o moznost vytvareni a ruseni kanalu a
   jejich presun mezi spravci.

   1. Uzivatel muze vytvaret a rusit kanaly prikazem (napr. "create
      #channel" a "destroy #channel"). Neni potreba zarucovat, ze kanaly
      budou v ramci site unikatni.

   2. Pripojovani, odpojovani a posilani zprav do kanalu jiz nebude
      vazano na jmeno spravce, ale na jmeno kanalu. Pokud nebude
      pozadavek na praci s danym kanalem schopen vykonat primo dany
      klient/spravce, preposle pozadavek vsem ostatnim spravcum,
      o jejichz existenci vi.

      Pri preposilani by mely byt osetreny situace, kdy muze dojit
      k zahlceni site nebo zacykleni preposilane zpravy (ignorovani
      zpravy, ktera jiz byla preposlana, time-to-live apod.).

   3. Pomoci specialni zpravy a prikazu (napr. "migrate #channel user")
      bude mozne presunout lokalne spravovany kanal (vcetne vsech
      prihlasenych) na jineho spravce. Pri ukonceni behu daneho spravce
      budou takto presunuty vsechny jim spravovane kanaly na libovolneho
      jineho spravce, o jehoz existenci vi (pokud takovy existuje).