** 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
  - gracz łączy się z serwerem
  - jeśli nikogo nie ma w poczekalni, sam do niej trafia
  - 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
  - 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
  - Dla zadań ze zdefiniowanym protokołem, zgodność z RFC lub inną specką
  - 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)