1. Multi-user Dungeon¶

Wieloosobowa gra tekstowa działająca w czasie rzeczywistym z prostym interfejsem użytkownika.

Gra zawiera centralny serwer koordynujący rozgrywkę, utrzymujący spójny i trwały świat gry oraz informacje o graczach. Do serwera mogą w dowolnym czasie podłączać się klienci pod warunkiem identyfikacji przez login/hasło.

Każdy klient jest osobnym graczem, steruje osobnym awatarem. Każdy gracz posiada ekwipunek. Gracze poruszają się po mapie świata, mogą wchodzić w interakcje ze znajdującymi się w swiecie przedmiotami (podnosić, odkładać) oraz awatarami innych graczy znajdującymi się w pobliżu (walczyć, rozmawiać).

2. Offline-available Chat¶

Aplikacja czatowa z mozliwością pisania także w przypadku braku połączenia z serwerem.

Klienci logują się za pomocą loginu/hasła do jednego lub więcej pokojów na centralnym serwerze. Klient może wysyłać wiadomości do pokoju, które będą rozsyłane do wszystkich innych użytkowników w danym pokoju. Wszyscy klienci widzą spójny stan rozmowy w kazdym pokoju (te same komunikaty w tej samej kolejności). Klienci widzą historię rozmów w pokoju.

Użytkownicy którzy stracili połączenie z pokojem mogą także pisać wiadomości, które będą rozesłane do innych użytkowników pokoju w czasie późniejszym.

3. Distributed Persistent Shared Memory w/ Master-slave Replication¶

Aplikacja implementuje rozproszony system pamięci współdzielonej.

Serwer Master zawiera pamięć współdzieloną w której zdalni klienci mogą definiowac nowe zmienne, nadpisywać ich wartości, oraz odczytywac wartości zmiennych.

Serwer jest replikowany w modelu master-slave. Serwer Master zawiera kopię główną danych, które mogą modyfikować klienci. W momencie modyfikacji Master rozsyła zmiany do swoich replik, które aplikują je do własnej kopii danych. Klienci mogą czytać z replik, ale nie mogą ich modyfikować.

Serwer i repliki mogą ulegać awariom. Jeśli awarii ulegnie Master, należy zapewnić, żeby inna replika została nowym serwerem Master.

4. Benchmark Execution Framework¶

System do wykonywania skoordynowanych obliczeń (benchmarks) na klastrze obliczenowym.

System składa się z wielu węzłów obliczeniowych, z których jeden jest wyróżniony jako koordynator. Klient wysyła do koordynatora zestaw programów i konfigurację wykonania programu. Konfiguracja okresla w jaki sposób programy mają być rozłożone na węzłach (np program A na węźle nr 4, program B na dowolnych 4 węzłach), jak mają być uruchamiane (np. program A jako pierwszy, potem programy B po 3 sekundach) i jakie produkują pliki (np. program B generuje plik /var/prog_b). Koordynator kopiuje programy na odpowiednie węzły. Kiedy wszystkie programy zostały zainstalowane, koordynator w sposób zsynchronizowany rozpoczyna wykonanie zgodnie z konfiguracją. Kiedy wszystkie programy się zakończyły, koordynator zbiera pliki wynikowe z węzłów i odsyła je do klienta.

Jeśli więcej niż jeden klient wyśle do koordynatora konfiguracje jednocześnie, zadaniem koordynatora jest rozpoznanie czy benchmarki mogą działać jednocześnie i ew. opóźnienie jednego z nich.

5. Peer-to-peer Filesharing¶

Zdecentralizowany system do współdzielenia plików.

System składa się z wielu węzłów obliczeniowych w topologii kliki. Każdy z klientów ma współdzielony katalog, z którego inni klienci mogą pobierać pliki. Każdy klient ma zagregowaną listę plików dostępnych do ściągnięcia (wg zawartości plików). Jeśli ściągany plik znajduje się jednocześnie na wielu węzłach klient powinien ściągać z wielu klientów jednocześnie, minimalizując czas ściągania. Użytkownik może w dowolnym momencie usunąć lub dodać pliki do katalogu współdzielonego, co powinno być wykryte przez klienta automatycznie i informacja powinna być rozpropagowana do pozostąłych węzłów.

Węzły mogą ulegać awariom, które powinny być obsługiwane wg modelu crash-recovery.

6. NoSQL Database¶

Baza danych oparta o drzewo.

System składa się z kilku serwerów i klientów. Każdy z serwerów ma w pamięci strukturę drzewiastą która reprezentuje bazę danych. Liście bazy danych zawierają dane heterogeniczne. Klienci mogą wysyłać do serwerów instrukcje które pozwalają im odczytać, zmodyfikować, dodać, lub usunąć dowolny fragment drzewa. Każdy serwer zapewnia że poszczególne operacje są wykonane atomowo i wydajnie poprzez zastosowanie odpowiednich mechanizmów synchronizacji (np. zamki nieskogranularne typu zapis/odczyt). Baza danych jest trwała – dane są zachowane w wypadku wyłączenia serwera i (częściowo) w wypadku awarii serwera.

7. Bitmap Pipeline¶

System rozproszonego potokowego przetwarzania obrazów.

System zawiera węzły w topologii kliki z jednym wyróżnionym koordynatorem. Użytkownik przygotowuje konfigurację przetwarzania i przesyła ją do koordynatora. Konfiguracja informuje o tym jaka transmitancja ma być uruchomiona na konkretnych węzłach oraz jak połączone są ze sobą węzły. Koordynator inicjalizuje węzły w sieci w taki sposób, żeby odpowiadały konfiguracji. Następnie użytkownik uruchamia przetwarzanie. System informuje użytkownika w momencie kiedy potok zakończy przetwarzanie. Użytkownik może poprosić koordynatora o przesłanie wyników przetwarzania z poszczególnych węzłów.

Węzły dzielą się na cztery typy: genererator, pochłaniacz, procesory binarne i procesory unarne. Wymagany jest jeden typ generatora, który czyta listę bitmap znajdujących się w jakimś katalogu i wysyła treść każdego z tych plików na swoje wyjście. Wymagany pochłaniacz czyta pliki przesłane na jego wejście i zapisuje je do jakiegoś katalogu. elementy unarne mają jedno wejście i jedno wyjście. Elementy unarne dostają na wejście bitmapy, dla każdej z tych bitmap aplikują jakąś transmitancję (np. negacja każdego piksela bitmapy, threshold, hałas) i wynik wysyłają na swoje wyjście. Elementy binarne działają podobnie, tylko mają dwa wejścia i jedno wyjście (przykładowo: suma, alternatywa, średnia).

System powinien wysyłać komunikaty między węzłami w sposób zapewniający wysoką przepustowość.

8. Faulty Board Game w/ Spectator Mesh¶

Gra planszowa ze spektatorami; z prostym interfejsem użytkownika.

W grze planszowej uczestniczy n węzłów-graczy połączonych klikę, z których jeden może być wyróżniony jako koordynator. Koordynator steruje przebiegiem rozgrywki: decyduje kiedy kończą się tury, kiedy rozpoczyna się i kończy rozgrywka. (Jeśli nie ma wyróznionego koordynatora, przebieg rozgrywki jest uzgodniony między połaczonymi ze sobą graczami.)

W dowolnym momencie do rozgrywki mogą dołączyć węzły-spektatorzy. Spektator nie uczestniczy w rozgrywce bezpośrednio: nie może wykonywac ruchów itp, ale obserwuje na bieżąco stan rozgrywki. Spektator dowiaduje się o stanie rozgrywki od jednego z klientów lub od innego spektatora.

Jeśli gracz ulegnie awarii rozgrywka kończy się lub kontynuuje bez niego (w zależności od gry). Jeśli awarii ulegnie spektator, rozgrywka jest kontynuowana. Jeśli ulegnie awarii spektator który informował o stanie rozgrywki innych spektatorów, to Ci spektatorzy są przekierowywani do innego spektatora lub gracza.

Przykładowa gra planszowa: Goblin Slayer.

Alternatywy¶

Możliwe jest zaproponowanie tematów projektów przez studentów: w takim wypadku wymagania są do uzgodnienia.

Możliwe jest zaproponowanie tematów projektów proponowanych przez innych prowadzących SK2 (szczegóły do uzgodnienia):

• http://www.cs.put.poznan.pl/jkonczak/sk2:projekt#fnt__1
• 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