Powrót na stronę UNIX

Projekt 2016 - wytyczne
Kalendarium:
4,10,11 V 17,18 V 24,25 V 31V,1VI 7,8 VI 14 VI
Konsultacje Check Point 1 Konsultacje Check Point 2 Oddanie finalne Oddanie spóźnione -5p
- 5 (6) p. - 15 (18) p. 24 (28) p. 19 (23) p.
- min. 3000
znaków opisu
- 60% kodu 100% kodu 100% kodu

W nawiasach podano punkty dla większych zadań. Na 1 punkt kontrolny wymagamy opisu (około 2 stron A4) planowanego rozwiązania (ile wątków, jaka między nimi synchronizacja, jak wygląda protokół sieciowy, na jakie moduły/funkcje będzie podzielony program. Na 2 punkt kontorlny ma działać minimum 60% kodu.

Powrót na stronę UNIX

Projekt Amb za 44p
Taksówki

W mieście o regularnym kształcie 10 na 10 przecznic kursują taksówki. Każda z nich steruje podłączony do serwera protokołem TCP gracz. Taksówki pozostają w ciągłym ruchu o stałej prędkości 1 przecznicy na 10 sekund. Ulice są wąskie i nie ma możliwości aby się wyminąć, zatem taksówki czasem ulegają kolizjom. W razie kolizji zatrzymują się naprzeciw siebie na 10s po czym obie zawracają. Jeśli taksówka dojedzie do granic miasta a sterujący nią gracz nie podejmie decyzji o skręcie to taksówka automatycznie skręca w losowym możliwym kierunku (prawo,lewo).

Co losowy czas [10-30 sekund] system generuje zlecenie polegające na odebraniu pasażera z punktu A i zawiezieniu go do punktu B. Gracz ma za zadanie znaleźć się w punkcie A a potem w punkcie B. Znalezienie się w punkcie A lub B skutkuje 10 sekundowym postojem. Tylko jeden gracz może zebrać zlecenie, w czasie jego wykonania nie może brać innych zleceń. System generuje maksymalnie 5 zleceń na raz.

Na początku każdy z graczy ma 100zł, każda kolizja kosztuje 50zł. Za każdy wykonany kurs gracz dostaje 20zł. Jeśli środki gracza się wyczerpią kończy on zabawę.

Nowo podłączony gracz ma zostać umieszczony w losowej pozycji co najmniej 3 przecznice od wszystkich innych graczy. Jeśli to nie jest możliwe należy odrzucić takiego gracza z stosownym komunikatem. Jest to jedyny limit na ilość graczy. Jeśli gracz się rozłączy w czasie wykonywania zlecenia to jego kurs jest anulowany. Jego taksówka po prostu znika z planszy.

Gracz po podłączeniu co 10 sekund ma automatycznie odrysowywaną mapkę sytuacyjną (tekstowa) z zaznaczoną pozycją wszystkich innych graczy wraz z pokazanym kierunkiem ich ruchu, wyróżnioną swoja pozycję i kierunek ruchu. Jeśli gracz nie ma aktualnie zlecenia to należy pokazać wszystkie otwarte zlecenia (punkty odbioru pasażera, jeśli realizuje zlecenie należy pokazać tylko punkt docelowy. Pokazujemy też aktualny stan środków gracza.

Gracz w każdej chwili może wydać komendę L lub P, która zmieni kierunek ruchu w daną stronę przy pierwszej nadarzającej się okazji. Decyzję można zmienić w każdej chwili (byle przed skrętem), stara dyspozycja jest wtedy anulowana. Jeśli na najbliższym skrzyżowaniu nie ma możliwości wybranego skrętu (jada po obrzeżu miasta to dyspozycja jest anulowana.

Każdy gracz ma być obsługiwany po stronie serwera przez oddzielny wątek. Jako klienta można użyć telnet.

Oceniający: Marcin Borkowski

Powrót na stronę UNIX

Projekt Bmb za 52p

Ten sam temat co Amb z następującymi modyfikacjami:

  1. Komunikacja po UDP, brak kontaktu z klientem powyżej 5s. oznacza rozłączenie. Klientem nie może być telnet.
  2. Zlecenia nie są generowane przez system, są to gracze drugiego typu. Klient podłącza się, wybiera punkty A i B po czym ogląda wizualizację (wyróżniamy aktualną pozycję i punkt docelowy) aż do momentu osiągnięcia punktu B, wtedy jest rozłączany. Za obsługę każdego gracza typu klient odpowiada oddzielny wątek po stronie serwera.
  3. Jeśli gracz typu taksówkarz rozłączy się w trakcie wykonywania zlecenia, jego pasażer jest pozostawiany w miejscu zniknięcia taksówki i czeka na innego taksówkarza.
  4. Rozłączenie się klienta nowego typu nie anuluje kursu, taksówkarz normalnie kończy go. Jeśli rozłączy się tez taksówkarz to kurs jest anulowany.

Oceniający: Marcin Borkowski

Powrót na stronę UNIX

Projekt Cjk za 44p

System obsługi wyścigów żółwi

W wyścigu żółwi startują zgłoszone wcześniej żółwie lądowe (dowolna liczba). Żółwie ścigają się na zamkniętym torze, mają do wykonania zadaną n okrążeń. Tor posiada k punktów kontrolnych, punkt kontrolny 0 na linii startu i kolejno ponumerowane punkty coraz dalej od startu. W trakcie wyścigu sędziowie obserwują tor i odnotowują osiągnięcie kolejnych punktów kontrolnych przez poszczególne żółwie. W sezonie odbywa się wiele wyścigów, na koniec sezonu podliczane są punkty. Najlepszy żółw w sezonie otrzymuje Złotą Sałatę.

Punktowane są pierwsze 4 miejsca w wyścigu:

  1. 25 punktów
  2. 10 punktów
  3. 5 punktów
  4. 1 punkt

Uwagi wstępne

Projekt należy wykonać w zgodzie z wymogami dotyczącymi wszystkich projektów, w szczególności: komunikacja po protokole IP, zastosowanie wątków POSIX. Kod źródłowy ma spełniać wymogi co do jakości.

Opis projektu

Napisać system do obsługi takich wyścigów dla Międzynarodowej Federacji Żółwiowej. System musi realizować następujące zadania:

System musi składać się z następujących komponentów:

Można przyjąć ograniczenie pozwalającego na podłączenie tylko jednego klienta organizatorów na raz. Liczba klientów relacjonujących nie może być ograniczona inaczej niż przez dostępność zasobów systemowych. Klient relacjonujący może podłączyć się w dowolnym momencie.

Serwer musi przechowywać dane w formie trwałej i musi być możliwość zamknięcia serwera, a następnie wznowienia z poprzednim stanem. W przypadku zamknięcia w trakcie trwania wyścigu, dopuszczalne jest utracenie danych o trwającym wyścigu.

Interfejs użytkownika wszystkich aplikacji i protokół komunikacyjny należy zaprojektować samodzielnie, tak aby zapewnić zadowalający poziom niezawodności.

Uwagi dodatkowe

Zawieszenie się lub utrata połączenia do dowolnego klienta nie może powodować zatrzymania systemu.

Wszystkie rozłączenia należy sensownie obsługiwać.

Oceniający: Jan Karwowski

Powrót na stronę UNIX

Projekt Djk za 52p

Rozproszony system przechowywania danych

Przygotować system, który pozwoli na przechowywanie plików sposób rozproszony: części plików będą rozdzielone pomiędzy wiele węzłów, każdy przechowuje tylko cześć pliku.

Uwagi wstępne

Projekt należy wykonać w zgodzie z wymogami dotyczącymi wszystkich projektów, w szczególności: komunikacja po protokole IP, zastosowanie wątków POSIX. Kod źródłowy ma spełniać wymogi co do jakości.

Opis

System ma się składać z:

Rolę klienta ma pełnić przeglądarka internetowa. Należy zaimplementować taki fragment protokołu HTTP, żeby możliwa była komunikacja z jedną z przeglądarek: Firefox, Chrome w zakresie podstawowego ściągania plików (podstawowej: w szczególności bez możliwości wznawiania).

System ma zapewniać konfigurowalny poziom niezawodności -- liczbę naturalną. Poprzez poziom niezawodności rozumiana jest maksymalna liczba węzłów slave, których usunięcie z systemu nie spowoduje utraty zawartości pliku. Poziom niezawodności dotyczy plików wgrywanych w danym momencie. Nie jest konieczne poprawianie rozmieszczenia pliku po usunięciu slave'a

Wszystkie dane i konfiguracja systemu mają być przechowywane w sposób trwały, umożliwiający zatrzymanie rozwiązania i jego ponowne uruchomienie.

Serwer główny (master)

Koordynuje działanie całego systemu. Zna listę wszystkich węzłów slave. Akceptuje połączenia od klientów do uploadu, HTTP, zarządzającego.

Interfejs HTTP serwera pod ścieżką / serwuje dokument HTML z listą plików na serwerze.

Serwer główny może przechowywać metadane dotyczące plików i ich położenia, ale nie może przechowywać zawartości plików.

Serwer przechowujący (slave)

Przechowuje właściwe zawartości plików, komunikuje się tylko z serwerem master.

Klient administracyjny

Pozwala na dodanie nowego węzła slave, usunięcie znanego węzła slave oraz wyświetlanie na żywo zdarzeń z serwera:

Klient do wgrywania plików

Pozwala wgrać plik z dysku na serwer.

Nawiązywanie i utrata połączenia ze slave

Rozwiązanie ma zapewniać sensowne zachowanie przy utracie połączenia ze slave lub przed jego nawiązaniem, w szczególności:

Po usunięciu z systemu liczby slave większej niż poziom niezawodności, który powoduje brak pewnej części pliku, taki plik zostaje w całości usunięty z systemu.

Wyraźnie rozróżniamy sytuację braku połączenia ze slave (tymczasowa) i usunięcia slave z klastra (permanentna)

Szczegóły implementacji

Niewyspecyfikowane protokoły sieciowe i interfejsy użytkownika należy zaprojektować samodzielnie.

Zawieszenie się, zablokowanie, zatrzymanie lub rozłączenie dowolnego klienta nie może powodować wstrzymania pracy serwera.

Oceniający: Jan Karwowski

Powrót na stronę UNIX