Projekty zaliczeniowe * Gra sieciowa (1 osoba) - jeden rodzaj gry na grupę (czyli jedne warcaby, jedno kik) - architektura klient-serwer - obsługa wielu równoległych sesji gry - 2 osoby na grę - prosta poczekalnia

  1. gracz łączy się z serwerem
  2. jeśli nikogo nie ma w poczekalni, sam do niej trafia
  3. w przeciwnym razie gra zaczyna się natychmiast z graczem z poczekalni

* Zdalna konsola typu Telnet (1 osoba) - klient-serwer (serwer - komputer do sterowania, klient - program dla użytkownika, operatora) - prosta powłoka, nie musi być opcji uruchamiania pełnego shella - muszą być operacje: zarządzanie plikami i folderami, wyświetlanie plików tekstowych, przechodzenie między folderami - uruchamianie prostych programów (tj. narzędzi, które nie wykorzystują pełni funkcji konsoli (np. biblioteka ncurses) - obsługa uwierzytelnienia (nie musi być faktyczne konto systemowe) - serwer linuksowy * System zdalnego zamykania systemów operacyjnych (1 osoba) - klient-serwer (serwer C&C, klient łączy się do C&C i czeka 

na polecenia z serwera)

- klient musi być dostępny na Windowsa i Linuksa. W zależności 

od systemu właściwe polecenie musi być wywołane

* Komunikator internetowy typu XMPP (1 osoba) - klient-serwer - komunikacja 1-1, z pośrednictwem serwera - lista znajomych lokalna (opcjonalnie na serwerze) - komunikacja tekstowa - statusy (dostępny, zw, zajęty, niewidoczny, niedostępny) * Komunikator internetowy typu IRC (2 osoby) - klient-serwer - protokół tekstowy, nie musi być zgodny z faktycznym IRC - obsługa wielu kanałów rozmów (tworzenie, usuwanie) - (opcjonalnie) obsługa DM-ów - użytkownik ma jeden nick per serwer - system uprawnień: właściciel, moderator 

właściciel: użytkownik, który jako pierwszy dołączył (czyli stworzył)
            do kanału, nie da sie go zbanować, czy wyrzucić.
            Rozważyć opcję zmiany ownera
moderator: wyznaczany przez właściciela, może banować i kickować,
           wyrzucić go może tylko właściciel, inny moderator nie

* Telefon internetowy (2 osoby) - p2p, klient-serwer dla statusów osób (opcjonalne) - rozmowy głosowe - preferowany protokół SIP do sygnalizacji, ale nie ma przymusu * Grupowy edytor plików tekstowych (2 osoby) - klient-serwer - pliki są na serwerze, klient może wybrać, który plik chce edytować lub 

utworzyć nowy

- każda edycja jest na bieżąco wysyłana do serwera i zwracana innym userom - idealnie: pozycja kursora wszystkich uczestników

* Prosty serwer protokołu HTTP (2 osoby) - częściowa implementacja serwera protokołu HTTP 1.1 (RFC 2616) - obsługa żądań GET, HEAD, POST, PUT, DELETE - do wyboru: funkcjonalność reverse proxy lub serwer dokumentowy tj: GET /plik.txt pobiera plik (jak każde Apache) POST /plik2.txt tworzy plik na serwerze z treścią w requeście PUT /plik.txt zastępuje plik na serwerze zadaną treścią DELETE /plik2.txt usuwa plik z serwera - tylko serwer * Prosty serwer protokołu FTP (2 osoby) - częściowa implementacja serwera protokołu FTP (RFC 959) - minimum obsługa komend: ascii, binary, mkdir, rmdir, put, get - tylko serwer

* Program do wymiany plików P2P (2-3 osoby) - architektura P2P - protokół wymiany plików - dowolny - obsługa wielu stron transmisji - wystarczy, że strony transmisji będą znane przed rozpoczęciem wymiany danych (2 osoby) - (3 osoby) katalog plików sieci P2P i dynamiczne dołączanie/rozłączanie komunikacji * Zaawansowana Gra Sieciowa (2-3 osoby) - architektura klient-serwer, p2p lub mieszane - obsługa wielu równoległych sesji gry (dla klient-serwer) - 3+ osoby na grę - poczekalnia

  1. brak narzuconej metody, może być kod dołączenia, może być algorytm

game matchingu

Zasady zaliczenia projektów * Wymogi podstawowe Aplikacja musi realizować komunikację sieciową Wykorzystanie protokołu TCP Serwer *musi* działać na Linuksie Języki programowania: dowolne, nowożytne pozwalające działać a) współbieżnie (serwer) b) na gniazdach sieciowych Klient: na komputerze (Windows i/lub Linux) lub urządzeniu mobilnym * Wymogi organizacyjne - Kody projektów muszą być utrzymane w systemie kontroli wersji (np. git) Można skorzystać z publicznego hostingu (GitHub, GitLab) lub lokalnej instancji GitLaba (https://gitlab.cs.put.poznan.pl) - W repo *musi* znaleźć się plik README, w którym znajdzie się - temat projektu - opis protokołu komunikacyjnego - sposób kompilacji i uruchomienia (dla C/C++ podane użyte biblioteki, np. Boost, SDL, itp.) - Wszystkie programy muszą się poprawnie kompilować podążając za instrukcją z pliku README - W językach C/C++ konieczne użycie flagi -Wall podczas kompilacji - Na dwa dni przed planowaną datą oddania projektu należy wysłać mi na maila informację, wraz z linkiem do repo. Dla repo prywatnych, dodać mnie do osób mających dostęp GitHub: Norbitor GitLab: norbitor GitLab IIn: nlangner * Kryteria oceny - Poprawność implementacji komunikacji sieciowej (w mniejszym stopniu logiki 

samego projektu)

- Poprawność protokołu komunikacyjnego

  1. Dla zadań ze zdefiniowanym protokołem, zgodność z RFC lub inną specką
  2. Dla własnych protokołów - pokrycie zaplanowanej funkcjonalności

- Zgodność funkcjonalności projektu z uzgodnionym tematem i zakresem 

(przy przyznawaniu projektu dyskutujemy jego funkcjonalność)

- Przejrzystość i czytelność kodu (sensowny podział na funkcje, 

trzymanie się zasad DRY, SOLID - w ramach rozsądku, adekwatne nazwy
zmiennych, funkcji, obiektów)