Show page

Differences

This shows you the differences between two versions of the page.

--- so:teme:hackathon [2022/05/05 20:47]
maria.mihailescu [Regulament]
+++ so:teme:hackathon [2023/05/20 07:38] (current)
maria.mihailescu
@@ Line 1: / Line 1: @@
 ===== Hackathon SO =====
-Hackathon-ul presupune rezolvarea unui task propus de către echipa de Sisteme de Operare, din materia parcursă în cadrul cursului si laboratoarelor de SO. Challenge-ul este propus spre a fi rezolvat de către o echipă de 2 studenți înscriși la cursul de Sisteme de Operare. Primele 3 cele mai bune implementări vor fi recompensate cu premii.
+Hackathon-ul presupune rezolvarea unui exercițiu propus de către echipa de Sisteme de Operare, din materia parcursă în cadrul cursului si laboratoarelor de SO. Exercițiul este propus spre a fi rezolvat de către o echipă de 2 studenți înscriși la cursul de Sisteme de Operare. Primele 3 cele mai bune implementări vor fi recompensate cu premii.
-În timpul desfășurării hackathon-ului, echipele vor primi live support din partea echipei de SO.
+În timpul desfășurării hackathon-ului, echipele vor primi ajutor din partea echipei de SO.
 ==== Obiective ====
@@ Line 12: / Line 12: @@
 ==== Data ====
-Sâmbătă, 7 mai 2022, în intervalul **9:00 - 17:30**.
+Sâmbătă, 20 mai 2023, în intervalul **9:00 - 17:00**.
 ==== Locație ====
-Hackathonul se desfășoară în mod hibrid. O echipă poate participa fie fizic (la facultate), fie online (pe MS Teams).
+Hackathonul se desfășoară în format fizic în sala PR706.
-  * Fizic (EG405, sala Bitdefender)
-  * Online (Microsoft Teams)
 ==== Precondiții ====
-  - La acest hackathon vor putea participa studenții înscriși la cursul de SO în anul universitar 2021-2022;
+  - La acest hackathon vor putea participa studenții înscriși la cursul de SO în anul universitar 2022-2023;
   - Participanții vor forma echipe de câte două persoane;
   - Participanții vor lucra pe propriile sisteme.
@@ Line 28: / Line 26: @@
 ==== Înscriere ====
-Echipele participante se vor putea înscrie la hackathon prin completarea formularului de [[https://forms.gle/tDV29arYEsuDdqgq9|aici]] până pe data de 4 mai 2022, ora 14:00. Se vor alege maxim 20 de echipe.
+Echipele participante se vor putea înscrie la hackathon prin completarea formularului de [[|aici]] până pe data de 17 mai 2023, ora 20:00. Se vor alege maxim 20 de echipe.
 ==== Regulament ====
-  - Codul versionat trebuie să fie adăugat într-un repository **privat** folosind platforma [[https://gitlab.cs.pub.ro/ | GitLab a facultății]]. Faceți un repo privat în care adăugați asistenții supraveghetori și un ReadMe cu componența echipei.
+  - Codul versionat trebuie să fie adăugat într-un repository **privat** folosind platforma [[https://gitlab.cs.pub.ro/ | GitLab a facultății]]. Faceți un repo privat în care adăugați asistenții supraveghetori și un README cu componența echipei.
-  - Codul trebuie să fie portabil (să fie dezvolat pentru platformele Linux și Windows).
   - Codul trebuie să treacă un set de teste puse la dispoziție de către echipa de SO.
+=== Submisie ===
+Submisiile vor fi încărcate pe [[https://curs.upb.ro/2022/mod/assign/view.php?id=193342| Moodle ]].
+  * O submisie constă într-o arhivă ''.zip'' care conține directorul ''so/hackathon/lambda-loader'' (cu directoarele ''checker'' și ''skel'').
+  * Arhiva este încărcată doar de unul dintre membrii echipei.
+  * În ''so/hackathon/lambda-loader/skel'' trebuie să existe un fișier ''README.md'' care să conțină:
+    * componența echipei
+    * link GitHub/GitLab
+    * detalii legate de implementare; fiecare funcționalitate extra are nevoie de o descriere, mod de abordare și testare.
 ==== Premii ====
 Fiecare membru al echipelor câștigătoare va fi premiat, în funcție de locul obținut:
-  - Premiul 1: Monitor
+  - Premiul 1: voucher eMag în valoare de 900 lei
-  - Premiul 2: Smartwatch
+  - Premiul 2: voucher eMag în valoare de 800 lei
-  - Premiul 3: Dronă
+  - Premiul 3: voucher eMag în valoare de 700 lei
 ==== Echivalare ====
 Toate echipele participante sunt **eligibile** de echivalarea unui punct din notele pentru temă în cadrul materiei Sisteme de Operare (în funcție de **__complexitatea implementării__ și __stadiului proiectului dezvoltat în timpul hackathonului__**).
+<hidden>
+TODO: adăugare link către regulamentul de echivalări
+</hidden>
 ==== Anunțare câștigători ====
-Echipele câștigătoare vor fi anunțate marți, 10 mai 2022.
+Echipele câștigătoare vor fi anunțate până joi, 25 mai 2023.
 ===== Dezvoltarea aplicației =====
@@ Line 56: / Line 66: @@
 <note important>
-Nu rulați testele //''local''// (pe calculatoarele voastre sau în mașinile voastre virtuale). Pot să apară diferențe între local și VM-uri, iar, pentru corectare, noi vom considera doar mașinile virtuale de la SO.
+Nu rulați testele //''local''// (pe calculatoarele voastre sau în mașinile voastre virtuale). Pot să apară diferențe între local și VM-uri, iar, pentru corectare, vom considera doar rezultatele obținute în mașina virtuală de la SO.
 </note>
+==== Loader de funcții lambda ====
+Proiectul constă în realizarea unui sistem care permite încărcarea dinamică a unor biblioteci și executarea unor funcții din acestea. Proiectul implementează o arhitectură de tip client - server, unde serverul primește cereri de rulat funcții dintr-o anumită bibliotecă dinamică din sistem.
+Funcționalitatea este primul pas spre implementarea unei funcționalități similare [[https://aws.amazon.com/lambda/ | AWS Lambda]], unde utilizatorul poate să încarce o funcție și să o execute pe diferite servere, la cerere; în cazul proiectului propus, funcțiile sunt deja implementare în biblioteci, iar clientul cere executarea anumitor funcții printr-o comandă trimisă serverului. Mai jos sunt detaliate cerințele principale ale temei, precum și posibile îmbunătățiri.
+=== Detalii și observații implementare ===
+Pentru implementare se pune la dispoziție funcționalitatea de primire de comenzi (folosind UNIX sockets), care conțin numele unei biblioteci (calea către fișierul cu biblioteca) și opțional numele unei funcții. O comandă trimisă de la client către server are următorul format: ''<libname> [<funcname> [<filename>]]'' unde:
+  * ''libname'' - calea spre biblioteca ce se dorește a fi utilizată
+  * ''funcname'' - parametru opțional; numele funcției din cadrul bibliotecii; în mod implicit, funcția folosită este numită ''run''.
+  * ''filename'' - parametru opțional; numele unui fișier cu date de intrare dat ca argument funcției ''funcname''.
+Datele rezultate în urma execuției vor fi scrise într-un fișier al cărui nume este întors ca răspuns clientului. Fișierul returnat va conține **doar** mesajele afișate la standard output de către funcția de bibliotecă apelată.
+Comunicarea între client și server este următoarea:
+<code>
+Client						    Server
+						    listen()
+connect()					    accept()
+send()     -—---libname [funcname [filename]]-----> recv()
+recv()     <--------------outputfile--------------- send()
+</code>
+După primirea și parsarea unui mesaj din partea unui client, serverul apelează secvențial o serie de funcții care au următoarele scopuri:
+  * Prepare / pre-hooks - operații pregătitoare de care nu depinde încărcarea bibliotecii sau executarea funcțiilor din bibliotecă;
+  * Încărcare bibliotecă - încărcarea bibliotecii și alte operații asociate gestiunii bibliotecii
+  * Execuție funcționalitate cerută - rularea funcției din bibliotecă. Dacă ''funcname'' lipsește, atunci se apelează funcția ''run''. Parametrul ''filename'' poate să apară doar atunci când este specificat ''funcname''.
+  * Descărcare bibliotecă - realizarea de operații asociate descărcării bibliotecii din memorie
+  * Post-hooks - operații ulterioare execuției care nu depind de prezența bibliotecii în memorie.
+<note tip>
+Cele 5 funcții au caracter orientativ. În funcție de implementare, unele funcții pot să nu fie implementate. În acest caz, funcțiile vor rămâne ca stub-uri.
+</note>
+<note important>
+Implementarea serverului trebuie paralelizată astfel încât cererile clienților să fie tratate cât mai rapid. Fiecare echipă trebuie să decidă modelul de paralelizare (prin procese, prin threaduri, hibrid, folosirea unui work pool etc.) luând în considerare scopul proiectului.
+</note>
+Funcționalitatea de bază presupune implementarea în C, pentru sistemul de operare Linux, folosind API-ul POSIX:
+  * conexiunii între client și server.
+    * Conexiunea client-server se va face folosind UNIX Sockets, prin intermediul bibliotecii libipc.so.
+    * Veți adăuga funcțiile necesare pentru creare, conectare, trimitere/primire de date în această bibliotecă (''libipc.so'').
+    * Puteți modifica biblioteca în orice mod doriți atât timp cât clientul de test (''checker/client.c'') compilează și se poate conecta la server.
+    * Clientul de test (''checker/client.c'') nu poate fi modificat. Dacă aveți nevoie să modificați clientul de test pentru funcționalități adiționale, creați un client nou de test.
+  * comunicației dintre client și server: clientul trimite o cerere respectând formatul de mai sus și așteaptă ca răspuns calea către un fișier din sistem în care se află rezultatele; serverul primește cererea din partea unui client și o tratează.
+  * tratării unei cereri de către server: serverul parsează comanda primită, încarcă biblioteca și apelează funcția cerută din bibliotecă.
+    * În caz de eroare, se va scrie următorul mesaj în fișierul de output ''Error: <command> could not be executed.'' urmat de mesaje de eroare sugestive (Hint: folosiți strerror()).
+    * Fișierul de output trebuie creat cu nume aleator folosind functia ''mkstemp()''. Folosiți ''OUTPUTFILE_TEMPLATE'' ca template pentru numele fișierului.
+  * trimiterii unui răspuns înapoi către client. Răspunsul este numele fișierului creat la pasul anterior pe baza ''OUTPUTFILE_TEMPLATE''.
+  * paralelizării modului de tratare a clienților.
+    * Aveți în vedere ca sincronizarea datelor de ieșire și încărcarea și descărcarea bibliotecilor nu trebuie să afecteze funcționalitatea celorlalte thread-uri / procese.
+<note warning>
+Aveți în vedere faptul că în implementarea voastră trebuie să asigurați buna funcționare a serverului: executarea funcțiilor dintr-o bibliotecă cerută de utilizator poate avea comportament neașteptat (ex. accese invalide, închideri forțate etc.). Implementarea serverului trebuie să fie robustă, iar serverul trebuie să își continue execuția și în aceste cazuri.
+</note>
+=== Concepte teoretice necesare ===
+De ce este nevoie pentru implementarea proiectului propus:
+  * Înțelegerea comunicării inter-proces  - folosirea Unix sockets și a operațiilor read/write sau send/receive:
+    * [[https://open-education-hub.github.io/operating-systems/Lecture/IO/|Curs I/O]]
+    * [[https://open-education-hub.github.io/operating-systems/I/O/| Laborator I/O]]
+  * Înțelegerea API-ului de încărcare / descărcare a bibliotecilor și executare de funcții din biblioteci dinamice:
+    * Hint: ''man dlopen''
+  * Lucrul cu date partajate între procese sau thread-uri:
+    * [[https://open-education-hub.github.io/operating-systems/Lecture/Compute/ | Curs Compute]]
+    * [[https://open-education-hub.github.io/operating-systems/Compute/|Laborator Compute]]
+  * Lucrul cu memoria
+  * Lucrul cu fișiere
+=== Testare ===
+== Exemplu rulare ==
+<code bash>
+## pornirea serverului
+so@so:~/skel$ ./server
+## client
+# se execută funcția "run" din libbasic.so
+so@so:~/checker$ ./client $(realpath libbasic.so)
+Output file: /home/so/checker/output/out-cfy0fl
+so@so:~/checker$ cat /home/so/output/out-cfy0fl
+run
+# se execută funcția "function" din libbasic.so
+so@so:~/checker$ ./client $(realpath libbasic.so) function
+Output file: /home/so/checker/output/out-vc7s03
+so@so:~/checker$ cat /home/so/output/out-vc7s03
+function
+# se execută funcția "cat" din libbasic.so cu argumentul "/home/so/checker/Makefile"
+so@so:~/checker$ ./client $(realpath libbasic.so) cat $(realpath Makefile)
+Output file: /home/so/checker/output/out-y732bN
+so@so:~/checker$ cat /home/so/output/out-y732bN
+CC=gcc
+[...]
+</code>
+== Rulare Checker ==
+Aveți la dispoziție un checker pentru verificarea parțială a implementării voastre.
+<code>
+so@so~$ cd checker
+so@so~$ ./checker.sh
+</code>
+=== Task-uri adiționale / departajare ===
+Funcționalitatea de bază este obligatorie pentru toate echipele participante. Pe lângă aceasta, pentru departajare, fiecare echipă poate aduce funcționalități adiționale aplicației. Fiecare funcționalitate extra va fi descrisă într-un fișier README (ce presupune și cum ați testat).
+Câteva funcționalități extra pe care le puteți avea în vedere (puteți propune voi orice altceva vi se pare necesar):
+  * interfață pentru conexiunea client - server: în funcție de parametrii dați la rulare, folosim sockeți de rețea sau sockeți UNIX.
+  * extinderea modului de tratare a unui client: serverul primește comenzi multiple până la întâlnirea comenzii "exit"/"quit" .
+  * securizarea serverului: cum previn leak-urile de date
+  * optimizări de performanță
+  * log-uri ale aplicației
+  * fișiere/opțiuni de configurare: la pornire, serverul este configurat în funcție de anumite opțiuni/fișiere de configurare: număr maxim de clienți, ce tip de sockeți să folosească, etc.
+  * inspectarea în timp real a serverului și extragerea de statistici (număr clienți, număr biblioteci încărcate, memorie consumată etc.)
+  * portarea spre alt limbaj de programare (scheletul propus este scris în C, însă, fiind vorba de comunicare client-server, implementarea poate fi în orice alt limbaj, atât timp cât respectă cerințele temei).
+  * trimiterea unui răspuns adecvat în care funcția cerută durează prea mult timp (peste un ''TIMEOUT'') sau a executat o operație care ar duce la oprirea serverului (ex: acces invalid la memorie, apelează exit/abort/etc). Soluția poate avea diferite niveluri de complexitate, funcție de modul în care este tratată terminarea conexiunii cu clientul (dacă clientul primește, sau nu, un mesaj de eroare) și cum se determină cauza terminării execuției.
+  * implementarea unui mecanism eficient de comunicare a rezultatelor în cazul folosirii network sockets (în acest caz, serverul poate întoarce un URL de unde clientul poate descărca rezultatele).
+  * închidere controlată a serverului (ex. la primirea unui semnal, se poate adăuga o rutină de tratare a semnalului care eliberează resursele înainte de închiderea serverului.
+<hidden>
 ==== In-memory cacher ====
@@ Line 79: / Line 218: @@
 Realizați o implementare minimală a unui serviciu cross-platform de in-memory cache care reține în memorie (RAM) logurile provenite de la diferite servicii din sistem.
 Proiectul va funcționa ca o arhitectură client-server, prin care:
-  * To be updated...
-<hidden>
   * un client (serviciu de sistem) se conectează la server (serviciul numit ''lmcd'')
   * clientul trimite mai multe comenzi către server:
@@ Line 90: / Line 227: @@
       * ''disconnect'' - închiderea conexiunii curente.
       * ''unsubscribe'' - dealocarea din memorie a datelor despre client **și** închiderea conexiunii curente.
-</hidden>
 ==== Precizări/recomandări pentru implementare ====
@@ Line 109: / Line 245: @@
 Proiectul conține două elemente principale:
-To be updated...
-<hidden>
   * **liblmc** - O bibliotecă prin care se expun către posibilii clienți funcțiile suportate de către serviciu: conectare, subscribe, adăugare de log-uri, forțare a scrierii datelor pe disk. Pentru a folosi aplicația de in-memory caching, un client trebuie să fie folosească biblioteca liblmc și să apeleze funcțiile expuse. Un exemplu în pseudocod de implementare a clientului ar putea fi următorul: <code>
 	struct lmc client;
@@ Line 120: / Line 253: @@
 </code>
   * **lmcd** - Un serviciu care primește comenzi de la clienți și implementează logica de in-memory cacher.
-</hidden>
 <note important>
@@ Line 134: / Line 265: @@
 ==== Structura de fișiere  ====
-To be updated...
-<hidden>
 Structura de fișiere prezentată mai jos conține următoarele componente:
   * ''include'' - director în care se află toate headerele folosite în proiect
@@ Line 175: / Line 303: @@
 |--- utils.c
 </code>
-</hidden>
 ==== Funcționalitatea de bază a aplicației ====
 Pentru funcționalitatea de bază a aplicației, trebuie implementate următoarele:
   * Comenzi:
-To be updated...
-<hidden>
        * ''connect'' - logica de conectare a unui client, păstrarea numelui clientului, precum și inițializarea structurilor interne.
        * ''add'' - adăugarea unei linii de log primite de la un client la cache-ul specific al clientului. O linie de log trimisă de la client către server are dimensiunea maximă LINE_SIZE și conține timestamp-ul (de la client) concatenat cu linia de log. Timestamp-ul are un format predefinit (TIME_FORMAT) și o lungime fixă (TIME_SIZE).
@@ Line 189: / Line 314: @@
       * ''unsubscribe'' - eliberarea datelor despre un client
       * ''disconnect'' - închiderea sesiunii curente a unui client.
-</hidden>
   * Paralelizarea clienților - interacțiunea cu clienții trebuie realizată în paralel. Rămâne la latitudinea voastră dacă folosiți procese sau fire de execuție.
   * Sincronizarea accesului la datele comune.
@@ Line 219: / Line 343: @@
 <note important>
 Pornirea server-ului pentru testare, cât și verificarea informațiilor afișate de server trebuie realizate de voi.
-Nu uitați să porniți serverul (''lmcd'' / ''lmcd.exe'') înainte să rulați checkerul.
-</note>
+<color red>**Nu uitați să porniți serverul (''lmcd'' / ''lmcd.exe'') înainte să rulați checkerul.** </color> </note>
 <note important>
-Deoarece testele (în general) nu realizează golirea datelor păstrate de server, este probabil ca dacă porniți același test de mai multe ori fără să opriți serverul să vedeți date adăugate de rulările anterioare ale clientului (ale unui test). Din acest motiv, verificarea testelor nu este realizată automat, și rămâne în grija voastră verificarea faptului că datele stocate sau întoarse de server sunt cele așteptate.
+Deoarece testele (în general) nu realizează golirea datelor păstrate de server, este probabil ca dacă porniți același test de mai multe ori fără să opriți serverul să vedeți date adăugate de rulările anterioare ale clientului (ale unui test). Din acest motiv, recomandarea este să opriți serverul și să ștergeți directorul de log-uri înainte de rularea unui test.
 </note>
@@ Line 267: / Line 391: @@
   * [[https://www.imaginarycloud.com/blog/redis-vs-memcached/]]
+</hidden>

Informații generale SO

Informații SO 2021-2022

Laboratoare

Curs

Accesibile pe GitHub, în organizația Open Education Hub, cu deployment prin Docusaurus.

Cursuri vechi

Teme

so/teme/hackathon.1651772831.txt.gz · Last modified: 2022/05/05 20:47 by maria.mihailescu

Show page Old revisions

Media Manager Back to top