Techniki Internetowe (TIN)

Regulamin projektu

Do zdobycia w ramach projektu jest 50 pkt.
Wymagane minimum do zaliczenia to 25 pkt.

Ocenie podlegać będzie dopiero finalna wersja projektu, jednak w czasie realizacji projektu należy zaliczyć kolejne kamienie milowe/etapy - za opóźnienia w ich zaliczaniu (tj. w przypadku rażąco złej jakości lub opóźnienia nadesłania akceptowalnej wersji) naliczane będą punkty karne w wymiarze 1 pkt. karny za każdy dzień spóźnienia. Liczy się data nadesłania pocztą elektroniczną akceptowalnej dla prowadzącego wersji, jednak ich rozliczenie wymaga osobistego spotkania z prowadzącym celem omówienia rezultatów.

Punktacja

1. (10 pkt.) zrealizowana funkcjonalność i działanie systemu.
2. (5 pkt.) architektura rozwiązania - podział na moduły, wątki/procesy, klasy itp.
3. (20 pkt. ale nie więcej niż 200% uzyskanych w A) jakość kodu:
   prawidłowe posługiwanie się interfejsem sieciowym, obsługa sytuacji krytycznych, ale także "klasyczne" aspekty programowania (np. zarządzanie pamięcią, "niesieciowe" sytuacje krytyczne, synchronizacja wątków/procesów, styl kodu).
4. (15 pkt.) dokumentacja projektowa - w tym:
   • (5 pkt.) opis użytkowy - funkcjonalności, użycia i innych wymagań, uwzględnienie sytuacji krytycznych i nietypowych, platform docelowych itp.,
   • (10 pkt.) opis techniczny - zarys architektury, modułów/obiektów i interfejsów pomiędzy nimi (może być opis formalny lub nie, ale musi być kompletny i jednoznaczny), szczegółowy opis protokołów i propozycji rozwiązania sytuacji krytycznych (np. chwilowa/trwała utrata łączności między węzłami, błędne pakiety, przekroczone limity czasowe, scenariusz "wstawania" poszczególnych węzłów systemu), scenariusze użycia, diagramy stanów, sekwencji itd., dokumentacja testowania wraz z uzasadnieniem i nawiązaniem do wymagań funkcjonalnych oraz niefunkcjonalnych
5. punkty karne za ew. opóźnienia.

Etapy i daty realizacji

1. ... jak najszybciej ... - uzgodnienie i uszczegółowienie tematów projektowych. Bez tego zabieranie się za projekt wstępny może nie mieć sensu...
2. 29.11.2021 - projekt wstępny (w postaci elektronicznej) zawierający te same informacje co dokumentacja końcowa, w zakresie adekwatnym dla projektu wstępnego. Projekt ten będzie w dalszym toku projektu uzupełniany do postaci dokumentacji końcowej. Z projektu tego ma jasno wynikać, że zespół wie co i jak ma realizować projektowany system, ale także, że każdy z członków zespołu ma jasno określone prace do wykonania.
3. 13.12.2021 - realizacja najniższej warstwy komunikacyjnej (obsługa gniazda), w tym "czyste" zakańczanie wszystkich procesów.
4. 03.01.2022 - realizacja wybranego podzbioru funkcjonalności, wymagającego interakcji wszystkich składników systemu.
5. 24.01.2022 - nadesłanie finalnej wersji projektu i dokumentacji.
6. 31.01.2022 - ostateczny termin wystawienia ocen (ok. 18:00).

Projekt należy zaprezentować i omówić osobiście całym zespołem.
Osoby przedstawiające swoje rozwiązania przed 2 czerwca mają szanse na wprowadzanie poprawek.

Projekt może być rozliczony tylko i wyłącznie po prezentacji jego działania w ramach dostępnych na Wydziale laboratoriów lub na sprzęcie własnym (np. laptopy) - każdy zespół jest odpowiedzialny za wcześniejsze rozeznanie w sytuacji i zorganizowanie niezbędnej infrastruktury na potrzeby prezentacji i rozliczenia projektu. Istnieje możliwość realizacji prywatnej podsieci na potrzeby takowej prezentacji - należy jednak przeprowadzić wcześniejsze "rozpoznanie" żeby uniknąć konsternacji w trakcie oddawania.
Proszę zwracać uwagę na sytuacje krytyczne (opóźnienia w sieci, chwilowe utraty łączności itp. - prawidłowa implementacja projektu powinna umieć sobie radzić z tego typu problemami).

Platformy

• Wszyscy piszą w C++ (ew. C) lub każdy pisze w innym języku.
• Komunikacja bezpośrednio przez gniazda.

Uwagi ogólne

• Niedopuszczalne jest, aby jakikolwiek wątek "zawieszał" się w oczekiwaniu na cokolwiek bez możliwości przerwania tego oczekiwania na żądanie. Są odpowiednie sposoby, aby funkcje synchroniczne wykonywać tylko wtedy, gdy jest po co. Dotyczy to zarówno komunikacji wewnętrznej jak i zewnętrznej.
• Wszystko co przychodzi z zewnątrz systemu jest potencjalnie niebezpieczne.
• Przetwarzanie przychodzących pakietów to ich parsowanie - wiedza z TKOM się przyda.
• Uruchamianie systemu rozproszonego nie może wymagać, by wszyscy administratorzy byli na raz w jednym pomieszczeniu.
• Wyłączanie systemu rozproszonego powinno moc przebiec w elegancki i kontrolowany sposób.
• Zaprojektowany podział zadań między wątki i procesy wpływa na ocenę, podobnie jak komunikacja między nimi i ich synchronizacja.
• Bezpieczeństwo danych oraz uwierzytelnianie i autoryzacja użytkowników są ważne.
• Zasoby trzeba zwalniać, nawet jeśli pomaga w tym garbage collector.
• Wyjątki, błędy etc. trzeba obsługiwać

Tematy Projektów

System monitorujący

Gra sieciowa

Sieciowy system plików

System do współpracy