Do zaliczenia pierwszej części laboratoriów (programowanie) należy zrealizować projekt ustalony z prowadzącym.

Przykładowe tematy projektów:

1. 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.
2. 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).
3. 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)
4. 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.
5. Sieciowa gra turowa – wybierz dowolną grę turową. Zamiast każdego gracza ruchy ma podejmować grupa graczy głosując na najlepszy ruch. Wymagane GUI¹⁾.
6. 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.
7. Messaage 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.
8. 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).
9. 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.
10. Inny projekt, uzgodniony z prowadzącym.

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
• http://www.cs.put.poznan.pl/mkalewski/files/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/ksiek/sk2/zadania.html

W związku z powtarzającymi się pytaniami o projekt: proponowane programy mają posiadać cechę zwaną po polsku użytecznością (ang: useability).
Podsumowując: program ma wygodnie działać w normalnych (a nie tylko laboratoryjnych) warunkach. W szczególności:

• 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.,
• 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ć),
• 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),
• dla niewielu często zmienianych parametrów wystarczy linia poleceń, w innym przypadku proszę używać plików konfiguracyjnych,
• 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),
• 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).

• Projekty są pisane w 2 osoby, chyba że uzgodniono inaczej z prowadzącym
• Uzgodnieniu projektu = mail do mnie z opisem projektu + moja odpowiedź OK
• Opis projektu najlepiej zrobić w postaci krótkiego przypadku użycia (use case [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 [2]
• W każdym projekcie serwer ma być pisany w C/C++ z użyciem BSD socket API do obsługi sieci
• Programy mają się kompilować bez ostrzeżeń (z flagą kompilatora -Wall)
• Kod zadań ma się pojawiać na repozytorium GIT: http://dsg.cs.put.poznan.pl/gitlab [lub innym dostępnym dla prowadzącego]
• Przyjęte rozwiązanie aspektów sieciowych wpływa na ocenę
• Jakość kodu wpływa na ocenę
• Kod będzie testowany analizatorami statycznymi (np. splint, cppcheck), wykonanie – dynamicznymi (np. valgrind)
• Projekt musi dać się łatwo zbudować – konieczne są pliki systemu budowania (ewentualnie opis jak skompilować kod)
• 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.

• Tematy projektów należy uzgodnić nie później niż do 4.12.2017
• 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.
• Prowadzący musi zostać poinformowany o skończeniu projektu nie mniej niż 3 dni przed oddaniem projektu.
• Oddanie projektów możliwe jest na ostatnich (lub przedostatnich, jeśli jest czas) zajęciach lub po mailowym uzgodnieniu z prowadzącym.
• Projekt należy oddać przed końcem okresu zajęć dydaktycznych semestru zimowego (tj. przed 28.01.2018).
• Do zaliczenia projektu konieczna jest pozytywna ocena z projektu.