Różnice

Różnice między wybraną wersją a wersją aktualną.

--- sk2:projekt [2018/01/26 10:13]
jkonczak [lit.]
+++ sk2:projekt [2025/11/03 21:47] (aktualna)
jkonczak
@@ Linia 1: / Linia 1: @@
-====== SK2 – projekt zaliczeniowy z programowania ======
+====== SK2 – projekt zaliczeniowy z programowania (2025/2026) ======
 Do zaliczenia pierwszej części laboratoriów (programowanie) należy zrealizować projekt __ustalony z prowadzącym__.
@@ Linia 5: / Linia 5: @@
 __Przykładowe__ tematy projektów:
-  - Ciągła synchronizacja katalogów pod Linuksem – program który dba o to, by zawartość katalogu u wszystkich klientów była taka sama. Zmiany plików są wykrywane natychmiastowo. Współbieżne zmiany są wykrywane i właściwie obsłużone.
+<html><div style="margin: -1.2em 0 0 0"/></html>
-  - Job scheduler – napisz prosty system kolejkowy: w serwerze rejestrują się węzły obliczeniowe, do serwera klienci wysyłają zadania do wykonania na węzłach (https://en.wikipedia.org/wiki/Job_scheduler).
+  - Wieloosobowa gra czasu rzeczywistego – dowolna gra w którą da się grać w więcej niż dwie osoby. Przykłady gier na których można się wzorować: [[https://archive.org/details/msdos_Jump_n_Bump_1998|jump 'n bump]], [[https://classicreload.com/bomberman.html|dyna blaster]], [[https://archive.org/details/CometBusters14Image|asteroids]].
-  - Reliable UDP multicast – napisz bibliotekę / protokół do realizacji niezawodnego przesyłania danych z użyciem UDP multicastu i użyj jej do budowy przykładowego programu (np. wysyłanie pliku)
+  - "Zręcznościowa" gra karciana / planszowa w której wiele osób naraz może wykonać ruch – np. dobble, jungle speed.
-  - Grupowy edytor grafiki wektorowej – napisz serwer i klienta programu, który pozwoli kilku osobom pracować naraz nad grafiką wektorową. Współbieżne operacje na tym samym obiekcie mają być obsłużone w praktyczny sposób.
+  - Quiz / gra państwa-miasta premiująca czas i unikalność odpowiedzi – gra po odpowiedzi od połowy graczy (lub upłynięciu czasu) generuje nowe pytanie. Przy nowym pytaniu serwer na podstawie poprawności, czasu odpowiedzi i odpowiedzi innych graczy przyznaje punkty i pokazuje odpowiedzi. Gracz może dołączyć w dowolnej chwili do gry.
-  - Sieciowa gra turowa – wybierz dowolną grę turową. Zamiast każdego gracza ruchy ma podejmować grupa graczy głosując na najlepszy ruch. Wymagane GUI((W tym projekcie wymagam wygodnego interfejsu użytkownika.
+  - Kahoot – serwer do którego można połączyć się w celu stworzenia quizu (na końcu tworzenia quizu otrzymuje się kod) lub z kodem, w celu wzięcia udziału w quizie. Serwer obsługuje wiele quizów naraz. Twórca po przygotowaniu i wystartowaniu quizu widzi na bieżąco jakie odpowiedzi udzielają uczestnicy. Uczestnicy widzą przynajmniej wzajemną punktację. Czas na pytanie kończy się po udzieleniu odpowiedzi przez 2/3 graczy, chyba że wcześniej minie limit czasu na pytanie.
-Jeśli napiszecie klienta np. w ncurses, też będzie ok.\\
+  - Wisielec – gracze razem odgadują litery kolejnych haseł – kto pierwszy ten lepszy, ale każdy gracz ma osobnego wisielca. Gracze widzą swoje wisielce nawzajem. Wszyscy widzą te same odsłonięte litery właśnie odgadywanego hasła. Za odgadniętą literę gracz dostaje punkt. Gra kończy się gdy zostanie jeden aktywny gracz.
-Por. nethack, dwarf fortress, adom, cavez-of-phear\\
+  - Układanie słów – serwer co rundę losuje określoną ilość liter i przesyła je graczom. Gracze wysyłają do serwera kolejne słowa dające się ułożyć z podanych liter. Gracz który podał jako pierwszy konkretne słowo dostaje punkty. Za słowo które nie daje się ułożyć z liter gracz traci punkty. Po określonym czasie serwer rozpoczyna następną rundę. Gracze widzą na bieżąco ranking z ilością punktów i dotychczas ułożone słowa.
-Z doświadczenia wiem, że w takim projekcie łatwiej napisać GUI
+  - Sieciowa gra turowa – dowolna gra turowa zmodyfikowana o to, że zamiast jednego gracza ruchy ma podejmować grupa graczy głosując na najlepszy ruch.
-niż interface tekstowy.)).
+  - Grupowy edytor grafiki wektorowej – serwer i klient programu, który pozwoli kilku osobom naraz pracować nad grafiką wektorową. Współbieżne operacje na tym samym obiekcie (np. zmiana rozmiaru i zmiana koloru) mają być sensownie obsłużone.
-  - Wieloosobowa gra czasu rzeczywistego – wybierz dowolną grę (w którą da się grać w więcej niż dwie osoby). Przykłady gier na których można się wzorować: jump&bump, dyna blaster, asteroids.
+  - Radio internetowe – serwer ma kolejkę plików dźwiękowych, które kolejno strumieniuje do wszystkich podłączonych klientów. Klienci mogą wgrywać na serwer nowe pliki, widzą bieżący stan kolejki i mogą wykonywać dowolne operacje na niej, mogą też zlecić przeskoczenie do następnego pliku z kolejki.
-  - Message queue – napisz message broker (serwer), bibliotekę klienta i demonstracyjny program używający tej biblioteki. Klient może tworzyć kolejki, wysyłać do nich wiadomości i zapisywać się do odbioru wiadomości z kolejki. Kolejki wspierają wielu konsumentów, wiadomości mają określony czas ważności.
+  - Ciągła synchronizacja katalogów – program który dba o to, by zawartość katalogu (rekurencyjnie) u wszystkich klientów była taka sama. Zmiany są wykrywane natychmiastowo. Współbieżne zmiany są wykrywane i właściwie obsłużone. W tym projekcie można nie robić GUI.
-  - HTTP caching proxy – proxy serwujące najczęściej pobierane strony z własnej pamięci (przykład programu – squid). Proxy ma redukować ruch (obsługa etag, if-modified-since, współbieżne żądania o tą samą stronę generują jedno zapytanie).
+  - Job scheduler – prosty system kolejkowy: w serwerze rejestrują się węzły obliczeniowe, do serwera klienci wysyłają zadania do wykonania na węzłach (por. [[https://en.wikipedia.org/wiki/Job_scheduler|job scheduler]], [[https://en.wikipedia.org/wiki/Slurm_Workload_Manager|slurm]]). Tutaj trzeba napisać serwer, klienta będącego węzłem i klienta będącego zlecającym zadanie. W tym projekcie można nie robić GUI.
-  - Serwer strumieniowania dźwięku – serwer ma kolejkę plików dźwiękowych, którą strumieniuje do wszystkich podłączonych klientów. Klienci mogą wgrywać na serwer nowe pliki, widzą bieżący stan kolejki i mogą wykonywać dowolne operacje na niej, mogą też zlecić przeskoczenie do następnego pliku z kolejki.
+  - Reliable UDP multicast – biblioteka / protokół do realizacji niezawodnego przesyłania danych z użyciem UDP multicastu i użycie jej do budowy przykładowego programu (np. wysyłanie pliku). W tym projekcie można nie robić GUI.
+  - Publish–subscribe message queue. Tutaj trzeba napisać trzy składniki – message broker (serwer), [[https://pl.wikipedia.org/w/index.php?title=Biblioteka_programistyczna|współdzieloną bibliotekę]] klienta i demonstracyjny program używający tej biblioteki. Klient może tworzyć kolejki, wysyłać do nich wiadomości i zapisywać się do odbioru wiadomości z kolejki. Kolejki wspierają wielu konsumentów, wiadomości mają określony czas ważności (por. [[https://en.wikipedia.org/wiki/Message_queue|message queue]]). W tym projekcie można nie robić GUI.
+  - HTTP(S) caching proxy – proxy serwujące najczęściej pobierane strony z własnej pamięci (przykład programu – [[http://www.squid-cache.org/|squid]]). Proxy ma redukować ruch (obsługa etag, if-modified-since, współbieżne żądania o tą samą stronę generują jedno zapytanie). W tym projekcie należy napisać tylko serwer i można nie robić GUI.
   - Inny projekt, uzgodniony z prowadzącym.
-<html><!--
-  - Prosty serwer HTTP ze wsparciem dla cgi/fcgi – Napisz serwer HTTP obsługujący GET i POST, który dla wybranego rozszerzenia pliku przekaże żądanie przez CGI/FCGI do np. php
-  - HTTP filter proxy – proxy filtrujące przechodzący ruch - np. wycinające ciasteczka i user agent (przykłady programów tego typu – WebCleaner, Privoxy)
-  - SOCKS5 – Napisz serwer proxy protokołu SOCK5 ([[https://en.wikipedia.org/wiki/SOCKS]], [[https://tools.ietf.org/html/rfc1928]])
-  - --></html>
+<small>
 Więcej pomysłów na projekty można znaleźć na stronach pozostałych prowadzących:
-  * http://www.cs.put.poznan.pl/ddwornikowski/courses/projekty_sieci2_2015.html
+<html><div style="margin: -1.2em 0 0 0"/></html>
-  * http://www.cs.put.poznan.pl/mkalewski/files/zadania.pdf
+  * http://www.cs.put.poznan.pl/mkalewski/files/zadania.pdf / https://www.cs.put.poznan.pl/mkalewski/edu/sk/doc/zadania.pdf
-  * http://www.cs.put.poznan.pl/jkonczak/misc/lukasz_tematy_projektow.pdf [projekty Łukasza Piątkowskiego, cached]
+  * http://www.cs.put.poznan.pl/mboron/prez/zasady_projektow.pdf
+  * http://www.cs.put.poznan.pl/agodzinski/project_2022.html
+  * [[https://web.archive.org/web/20190914225318/http://www.cs.put.poznan.pl/ddwornikowski/courses/projekty_sieci2_2015.html|http://www.cs.put.poznan.pl/ddwornikowski/courses/projekty_sieci2_2015.html]]
   * http://www.cs.put.poznan.pl/ksiek/sk2/zadania.html
+  * http://www.cs.put.poznan.pl/jkonczak/misc/lukasz_tematy_projektow.pdf [projekty Łukasza Piątkowskiego, cached]
+</small>
-==== Użyteczność! ====
+<small>
+Nieakceptowalne tematy projektów ze względu na brak wymaganej złożoności sieciowej:
-W związku z powtarzającymi się co roku pytaniami o projekt: proponowane programy mają posiadać cechę zwaną po polsku [[https://pl.wikipedia.org/wiki/U%C5%BCyteczno%C5%9B%C4%87_(informatyka)|użytecznością (ang: useability)]].\\
+<html><div style="margin: -1.2em 0 0 0"/></html>
-Podsumowując: program ma wygodnie działać w normalnych (a nie tylko laboratoryjnych) warunkach. W szczególności:
+  * Prosty komunikator internetowy.
-  * **ma działać w sieciach rozległych (przez internet) – czyli obsługiwać opóźnienia, brak informacji zwrotnej z funkcji connect (firewall), zerwanie połączenia, etc.,**
+  * Prosty czat internetowy.
-  * **ma uwzględniać że użytkownicy mogą się dowolnie łączyć, rozłączać (np. w trakcie kiedy serwer wykonuje na ich rzecz działanie), nie robić nic (np. w trakcie gry przestać głosować),**
+  * Gra w której kolejność ruchów graczy jest z góry znana, a opuszczenie gry przez gracza jest równoznaczne z końcem rozgrywki.
-  * parametry konfiguracyjne powinny być konfigurowalne, nie ustawione na sztywno w kodzie; proszę się też zastanowić co użytkownik może chcieć ustawić (i pozwolić mu na to),
+  * Kółko i krzyżyk.
-  * dla niewielu często zmienianych parametrów wystarczy linia poleceń, w innym przypadku proszę używać plików konfiguracyjnych,
+  * Pong.
-  * w interaktywnych projektach (edytor grafiki, gra) klienci mają widzieć co się dzieje (np. ktoś przesuwa figurę na rysunku, inny gracz oddał głos na ruch), w projektach gdzie klient widzi stan serwera (job scheduler, dropbox) zmiany stanu mają mu być pokazywane bez konieczności odpytywania (np. klient widzi że jego zadanie się skończyło, każda zmiana pliku jest bez zbędnej zwłoki synchronizowana a konflikty zgłaszane),
+</small>
-  * nie można wymagać wszechwiedzy od komponentów systemu: np. w job schedulerze klient nie będzie wiedział znikąd gdzie są maszyny obliczeniowe, od użytkowników komunikatorów internetowych nie należy wymagać znajomości adresu serwera (zamiast tego przykładowo dostarczyć z aplikacją plik konfiguracyjny).
 ===== Ogólne zasady i uwagi =====
-  * Projekty są pisane w 2 osoby, chyba że uzgodniono inaczej z prowadzącym
+  * Projekty są pisane w 2 osoby, chyba że uzgodniono inaczej z prowadzącym.
-  * **Uzgodnieniu projektu = mail do mnie z opisem projektu + moja odpowiedź OK**
+  * **Uzgodnieniu projektu = mail do mnie z opisem projektu + moja odpowiedź OK.**
-  * Opis projektu najlepiej zrobić w postaci krótkiego przypadku użycia (use case [[https://pl.wikipedia.org/wiki/Przypadek_użycia|[1]]]) z zaznaczoną rolą serwera i klienta \\ Opis projektu można też wykonać w sposób podobny jak na stronie z propozycjami projektów Konrada Sieka [[http://www.cs.put.poznan.pl/ksiek/sk2/zadania.html|[2]]]
+  * Opis projektu najlepiej zrobić w postaci krótkiego przypadku użycia (use case [[https://pl.wikipedia.org/wiki/Przypadek_użycia|[1]]]) z zaznaczoną rolą serwera i klienta. \\ Opis projektu można też wykonać w sposób podobny jak na stronie z propozycjami projektów Konrada Sieka [[http://www.cs.put.poznan.pl/ksiek/sk2/zadania.html|[2]]]. \\ **[[projekt_przykladowy_opis|Przykład opisu projektu]].**
-  * **W każdym projekcie serwer ma być pisany w C/C++ z użyciem BSD socket API do obsługi sieci**
+  * Tematy projektów mogą się powtarzać. Każda grupa musi przygotować własny opis projektu.
-  * Programy mają się kompilować bez ostrzeżeń (z flagą kompilatora ''-Wall'')
+  * Około miesiąc przed terminem oddania projektu (datę podam później) będę przeglądał kod źródłowy projektów. Przegląd kodu ma pomóc w poprawieniu jakości kodu i eliminacji błędów które się w nim zdążyły pojawić.
-  * Kod zadań ma się pojawiać na repozytorium GIT: https://gitlab.cs.put.poznan.pl/ [lub innym dostępnym dla prowadzącego]
-  * Przyjęte rozwiązanie aspektów sieciowych wpływa na ocenę
+===== Wymagania =====
-  * Jakość kodu wpływa na ocenę
-  * Kod będzie testowany analizatorami statycznymi (np. splint, cppcheck), wykonanie – dynamicznymi (np. valgrind)
+**Warunki które musi spełniać każdy projekt (i które muszą wynikać z wysłanego opisu):**
-  * Projekt musi dać się łatwo zbudować – konieczne są pliki systemu budowania (ewentualnie opis jak skompilować kod)
+<html><div style="margin: -1.2em 0 0 0"/></html>
+  * **Interakcja klientów ze sobą: projektu nie da się zrealizować tworząc izolowany wątek / proces dla każdego klienta.**
+  * **Konieczność obsłużenia wielu klientów naraz: serwer przez większość czasu może otrzymać wiadomość od więcej niż jednego klienta i kolejność (lub czas) otrzymania wiadomości ma znaczenie.**
+  * **Konieczność rozwiązania konfliktów: w trakcie działania mogą pojawiać się sytuacje, gdzie poprawna wiadomość od klienta jest niepoprawna / niespójna / sprzeczna dla serwera.**
+Języki programowania / biblioteki:
+<html><div style="margin: -1.2em 0 0 0"/></html>
+  * **W każdym projekcie serwer ma być pisany w C/C%%++%% z użyciem BSD socket API do obsługi sieci.**
+  * <small> Klient może być pisany w dowolnym języku, serwer (poza obsługą sieci) może korzystać z dowolnych bibliotek, ale: działający projekt musi być zaprezentowany w laboratorium, instalację egzotycznych bibliotek i kompilatorów na komputerach laboratoryjnych przeprowadzacie we własnym zakresie.</small>
+Sieć i liczba użytkowników:
+<html><div style="margin: -1.2em 0 0 0"/></html>
+  * **Program ma działać w sieciach rozległych (przez internet) – czyli obsługiwać opóźnienia, brak informacji zwrotnej z funkcji ''connect'' (firewall), zerwanie połączenia, etc.,**
+  * **Zaimplementowana logika ma uwzględniać że użytkownicy mogą się dowolnie łączyć, rozłączać (np. w trakcie kiedy serwer wykonuje na ich rzecz działanie), nie robić nic (np. nie udzielać odpowiedzi w quizie / kahoocie).** \\ <small>(W tym wymaganiu chodzi o to, żeby użytkownik łączący się "nie w porę" też dostał sensowny komunikat, a zakończenie / zerwanie / utrata połączenia bądź nieaktywność gracza nie wpłynęła negatywnie na pracę serwera; proszę nie próbować implementować "powracania" rozłączonego użytkownika.)</small>
   * Komunikacja klient-serwer ma odbywać się z wykorzystaniem protokołu TCP, chyba że temat projektu stanowi inaczej lub uzgodniono z prowadzącym użycie innych protokołów.
-  * Około miesiąc przed terminem oddania projektu (dokładny termin podam w grudniu) będę przeglądał kod źródłowy projektów. Przegląd kodu ma pomóc w poprawieniu jakości kodu i eliminacji błędów które się w nim zdążyły pojawić.
+  * Serwer musi nasłuchiwać na dowolnym adresie IP, a klient musi mieć możliwość wyboru adresu IP serwera bez ponownej kompilacji.
+  * Liczba klientów nie może być sztucznie ograniczona. Jeśli np. liczba graczy jest ograniczona przez zasady gry, to należy umożliwić wiele gier na serwerze. (Po uzgodnieniu z prowadzącym można uchylić to wymaganie, np. dla gier czasu rzeczywistego.)
+Rozwój oprogramowania:
+  * **Kod ma być rozwijany na repozytorium** https://git.cs.put.poznan.pl/ (lub innym, dostępnym dla prowadzącego bez konieczności logowania / posiadania konta w zewnętrznej usłudze).
+  * **Projekt musi dać się łatwo zbudować – konieczne są pliki systemu budowania** [[https://en.wikipedia.org/wiki/Build_automation|[1]]] [[https://en.wikipedia.org/wiki/List_of_build_automation_software|[2]]].
+  * Programy powinny kompilować się bez ostrzeżeń (np. dla kodu w C/C%%++%% z flagami kompilatora ''-Wall -Wextra'').
+  * Kod będzie testowany analizatorami statycznymi (np. cppcheck, [[https://clang.llvm.org/docs/analyzer/user-docs/CommandLineUsage.html|clang]]), wykonanie – dynamicznymi (np. [[https://valgrind.org/docs/manual/mc-manual.html|valgrind]]).
+GUI
+  * Wszystkie projekty wymagają GUI, chyba że w opisie/temacie zaznaczono inaczej.
+  * GUI ma działać. Na ocenę projektu nie ma wpływu to jak "ładne" jest GUI.
+===== Ocenianie ====
+Projekt jest wstępnie oceniany na:
+<html><div style="margin: -1.2em 0 0 0"/></html>
+  * 5.0 jeśli stworzone programy działają poprawnie w każdych warunkach sieciowych i realizują wszystkie aspekty zawarte w opisie projektu
+  * 4.0 jeśli stworzone programy działają poprawnie przynajmniej w typowej sieci lokalnej i realizują wszystkie aspekty zawarte w opisie projektu
+  * 3.0 jeśli pojawiają się błędy w działaniu programów lub nie zostały zrealizowane fragmenty opisu projektu
+Następnie ocena jest zwiększana / zmniejszana w zależności od:
+<html><div style="margin: -1.2em 0 0 0"/></html>
+  * przyjętych rozwiązań aspektów sieciowych
+  * jakości kodu
+  * błędów kompilacji, błędów zarządzania pamięcią, błędnej synchronizacji między wątkami, etc.
+  * braku spełnienia zasad opisanych na tej stronie (np. terminy, brak plików systemu budowania, brak repozytorium etc.)
+Często powtarzające się błędy które prawie zawsze skutkują obniżeniem oceny:
+<html><div style="margin: -1.2em 0 0 0"/></html>
+  * aktywne czekanie (nieważne czy dla synchronizacji wątków, czy do obsługi sieci)
+  * brak dzielenia przychodzących strumieniem TCP danych na logiczne komunikaty
+  * wysyłanie nadmiarowych danych przez sieć
 ===== Terminy =====
-  * **Tematy projektów należy uzgodnić nie później niż do 4.12.2017**
+  * **Tematy projektów należy uzgodnić nie później niż do 30.11.2025.** \\ Przekroczenie tego terminu skutkuje obniżeniem oceny o 0.5.
-  * O skończeniu projektu należy poinformować prowadzącego mailowo. Do tego czasu projekt musi być zaakceptowany przez prowadzącego i prowadzący musi mieć dostęp do kodu źródłowego.
+  * O skończeniu projektu należy poinformować prowadzącego mailowo. Do tego czasu opis projektu musi być zaakceptowany przez prowadzącego i prowadzący musi mieć dostęp do kodu źródłowego.
-  * Prowadzący musi zostać poinformowany o skończeniu projektu nie mniej niż 3 dni przed oddaniem projektu.
+  * **Mail z informacją o skończeniu projektu należy wysłać najpóźniej 04.01.2025**. \\ Przekroczenie tego terminu skutkuje obniżeniem oceny o 0.5.
-  * Oddanie projektów możliwe jest na ostatnich (lub przedostatnich, jeśli jest czas) zajęciach lub po mailowym uzgodnieniu z prowadzącym.
+  * **Działający projekt należy zaprezentować w laboratorium przed końcem okresu zajęć dydaktycznych semestru zimowego (tj. najpóźniej 03.02.2025)**.
-  * **Projekt należy oddać przed końcem okresu zajęć dydaktycznych semestru zimowego (tj. przed 28.01.2018)**.
+  * Wysłanie maila z informacją o skończeniu projektu a zaprezentowanie projektu w laboratorium muszą dzielić przynajmniej 2 dni (na przejrzenie kodu przez prowadzącego).
-  * Do zaliczenia projektu konieczna jest pozytywna ocena z projektu.
+  * Zaprezentowanie projektu w laboratorium projektów możliwe jest na/po zajęciach lub po mailowym uzgodnieniu z prowadzącym.
+  * Do zaliczenia przedmiotu konieczna jest pozytywna ocena z projektu.

Jan Kończak

Narzędzia użytkownika

Narzędzia witryny

Różnice

Narzędzia strony