Dydaktyka‎ > ‎

Sieci komputerowe (lato 2009)

Contents

  1. 1 Ogłoszenia
  2. 2 Terminarz zajęć
  3. 3 Uwagi odnośnie zajęć
    1. 3.1 Poczta elektroniczna
    2. 3.2 Oddawanie rozwiązań przez zespół
  4. 4 Komentarze do list zadań
    1. 4.1 Zadanie programistyczne 1
    2. 4.2 Zadanie programistyczne 2

Ogłoszenia

  • 21-04-2009 - Zadanie 3 z L3 należy oddać e-mailem do 23:59 dnia 27-04-2009.
  • 25-04-2009 - W związku z dużym chaosem w oddawaniu zadań zamieszczam nowe wytyczne dla zespołów.
  • 26-04-2009 - Sprawdziłem pracownię programistyczną numer 1. Osoby, które oddawały zadania na zajęciach, a nie przesłały ich e-mailem, muszą przesłać rozwiązania do 23:59 dnia 28-04-2009. W przeciwnym wypadku zadania będą niezaliczone.
  • 03-05-2009 - Sprawdziłem zaległe rozwiązania z pracowni programistycznej numer 1 i zadanie 3 z laboratorium numer 3.
  • 06-05-2009 - Lista 7 z laboratorium i pracownia programistyczna 2 ma zostać wysłana do 23:59 dnia 12-05-2009.
  • 13-05-2009 - Termin oddania zadania z pracowni programistycznej 2 został przełożony do 23:59 dnia 17-05-2009. Jest to ostateczny termin. Przypominam o konieczności poinformowania o ewentualnych zmianach w zespołach.
  • 13-05-2009 - Przypominam o konieczności uzgodnienia projektów na pracownię programistyczną 3. Najlepiej robić to osobiście.
  • 02-06-2009 - Osoby zainteresowane odrabianiem zajeć z powodu nieobecności, będą to mogły zrobić po ćwiczeniach 9 czerwca lub w innym ustalonym prywatnie terminie.
  • 02-06-2009 - Po dzisiejszych ćwiczeniach będą kontynowane zeszłotygodniowe zajęcia z laboratorium (listy 8 i 10).
  • 10-06-2009 - Dotyczy osób, które nie wpisały się na kartkę na ostatnich ćwiczeniach: Osoby zainteresowane odrabianiem nieobecności muszą wysłać list z informacją, które listy chcą zadeklarować. Według regulaminu musicie przynieść zwolnienie lekarskie.
  • 11-06-2009 - Dodałem do arkuszy kolumny wyliczające oceny.
  • 01-07-2009 - Wszystkich zainteresowanych wpisami przypominam, że indeksy można i należy zostawiać na mojej półce :-)

Terminarz zajęć

  1. 03-03-2009 - odwołane
  2. 10-03-2009 - ćwiczenia (lista 1) + pracownia (lista 1)
  3. 17-03-2009 - ćwiczenia (lista 2)
  4. 24-03-2009 - ćwiczenia (lista 3)
  5. 31-03-2009 - laboratoria (lista 3)
  6. 07-04-2009 - pracownia programistyczna (lista 1)
  7. 14-04-2009 - święta wielkanocne
  8. 21-04-2009 - laboratoria (lista 4)
  9. 28-04-2009 - ćwiczenia (lista 6)
  10. 05-05-2009 - ćwiczenia (lista 7)
  11. 12-05-2009 - pracownia programistyczna (lista 2)
  12. 19-05-2009 - ćwiczenia (lista 9)
  13. 26-05-2009 - laboratoria (lista 8), laboratoria (lista 10)
  14. 02-06-2009 - ćwiczenia (lista 10), c.d. laboratorium (lista 8 i 10)
  15. 09-06-2009 - ćwiczenia (lista 11)
  16. 16-06-2009 - laboratoria (lista 12), pracownia programistyczna (lista 3)
  17. 19-06-2009 - od godziny 17:00 dodatkowe zajęcia dla osób zainteresowanych odrabianiem nieobecności.

Uwagi odnośnie zajęć

  • Na zajęciach obowiązuje regulamin wykładowcy: http://www.ii.uni.wroc.pl/~mbi/dyd/sieci_09s/mat/zasady.pdf
  • Dopuszczalnymi językami programowania na pracowni programistycznej są C / C++ / Python.
  • Program ma obowiązkowo działać na Linuksie i wykorzystywać mechanizmy wbudowane w ten system operacyjny.
  • Dopuszczalnymi bibliotekami dla w/w języków są biblioteki standardowe tj.:
    • GNU libc ( włączając pthreads )
    • STL ( również TR1, jeśli ktoś bardzo potrzebuje )
    • biblioteki wbudowane Pythona 2.6 ( z pewnymi ograniczeniami, które pojawią się w komentarzach do zadań )
  • Dodatkowo dla niektórych zadań mogą się pojawić dodatkowe biblioteki niezbędne do ich wykonania.
  • Użycie każdego innego języka / biblioteki należy ze mną konsultować.
  • Programy będą dodatkowo sprawdzane na poprawność względem działania w środowisku wielowątkowym.

Poczta elektroniczna

Wszystkie listy skierowane do mnie należy wysyłać na adres: <X@ii.uni.wroc.pl> gdzie X = cahirwpz.

Każdy list powinien posiadać:

  • W polu "From" należy wpisać swoje imię i nazwisko np.: "Nullisław Voidziński <nullislaw.voidzinski@gwiazdka.com>".
  • W polu "Subject" należy wpisać "[Sieci][wt.16]" lub "[Sieci][wt.18]" (w zależności od grupy) jako prefiks tematu.
Jeśli do listu chcecie dodać rozwiązanie indywidualne to:
  • Chcę je dostać jako archiwum - tylko jeden załącznik!
  • Archiwum ma być w formacie zachowującym uprawnienia uniksowe - dopuszczalne to ".tar.gz" / ".tar.bz2".
  • Bazowa nazwa załącznika musi być w formacie "XY-Z" (np. P2-234567), gdzie:
    • X = P / C / L - odpowiednio: pracownia programistyczna / ćwiczenia / labolatoria
    • Y - numer listy zadań
    • Z - indeks oddającego
UWAGI: Powyższe wymagania proszę traktować poważnie. Jeśli nie będziecie ich stosować wasze listy mogą zagubić się w mojej skrzynce pocztowej.

Oddawanie rozwiązań przez zespół

Zadania na pracownię programistyczną wymagają pracy w zespołach. W związku z tym przed wysyłaniem indywidualnych rozwiązań przywódca zespołu musi wysłać do mnie list zawierający informacje o członkach drużyny tj. nazwiska i numery indeksów. W odpowiedzi na rejestrację zespołu odpowiem jego identyfikatorem (np. T03), który będzie niezbędny do wysyłania rozwiązań indywidualnych.

Dla każdego zespołu założę katalog, do którego będę wrzucał część wspólną działania zespołu (np. specyfikację). Część wspólna musi zostać wysłana przez przywódcę zespołu w postaci archiwum:
  • Spełniającego wymogi z podpunktu "poczta elektroniczna", z wyjątkiem ostatniego.
  • Bazowa nazwa musi być w formacie "PY-Z" (np. P2-T03), gdzie:
    • Y - numer listy zadań
    • Z - identyfikator zespołu
Każdy członek zespołu musi mi przesłać rozwiązanie indywidualne (chyba, że nie jest wymagane) w postaci archiwum:
  • Spełniającego wymogi z podpunktu "poczta elektroniczna", z wyjątkiem ostatniego.
  • Bazowa nazwa musi być w formacie "PX-Y-Z" (np. P2-T03-234567), gdzie:
    • X - numer listy zadań
    • Y - identyfikator zespołu
    • Z - indeks oddającego
UWAGI: Jak do punktu "poczta elektroniczna". Stosowanie się do w/w wytycznych będzie ułatwiało mi pracę. W waszym interesie jest, żebym nie pogubił się w rozwiązaniach ;-)

Komentarze do list zadań

Jeśli zadania lub moje komentarze są niejasne lub niewystarczające należy wysłać do mnie list.

Zadanie programistyczne 1

Należy użyć jednego z dwóch mechanizmów blokowania plików:

Zadanie programistyczne 2

Aplikację sieciową można zaprojektować na trzy (meta-)sposoby:
  • process per client - dla każdego nowego klienta startujemy nowy proces ( np.: fork )
  • thread per client - j.w ale startujemy nowy wątek ( np.: pthread_create )
  • event-driven based - obserwujemy wszystkie połączenia, gdy zmieni się stan któregokolwiek z nich obsługujemy po kolei i wracamy do obserwowania ( np.: poll, epoll, select, kqueue )
W miarę składny artykuł mówiący o programowaniu architektury process / thread per client: Client-Server Architecture

Wersja trzecia jest najabmitniejsza i jednocześnie najwydajniejsza w praktyce - pod warunkiem, że:
  • korzystamy z wzorca projektowego Proactor,
  • obsługę zdarzeń rozdzielamy między pewną ilość wątków zależną od liczby procesorów.
W trakcie pisania na pewno natkniecie się na jakieś pułapki - poniżej lista najczęściej spotykanych :)
  • recv(...) / read(...) mogą zwrócić 0 - oznacza to, że strona przeciwna zamknęła połączenie w grzeczny sposób
  • recv(...) / read(...) mogą zwrócić dowolną ilość danych nie większych niż wielkość podanego bufora. Nawet jeśli po przeciwnej stronie wysyłacie pakiet jednym wywołaniem, po drugiej stronie jego odczytanie może wymagać kilku odwołań do wymienionych procedur.
  • przy zerwaniu połączenia do procesu domyślnie jest dostarczany sygnał SIGPIPE - trzeba to jakoś obsłużyć (np. nakazać ignorowanie)
  • póki proces nie odbierze statusu procesu potomnego ten drugi będzie istniał w systemie jako Zombie
  • w przypadku błędu większość funkcji uniksowych zwraca -1, a faktyczny błąd podaje w zmiennej errno.
UWAGA! Proszę nie programować jakichś niesamowicie skomplikowanych interfejsów tekstowych do aplikacji!

Założenie jest takie, żeby klient posiadał możliwie najprostszy interfejs, który będzie umożliwiał nie tylko obsługę z linii poleceń, ale również sprawne przeprowadzanie testów (np. przez skierowanie pliku na standardowe wejście). Klient ma przyjmować dane z stdin, a wyrzucać na stdout. Na stderr można wyrzucać dodatkowe komunikaty diagnostyczne.

Proszę zaprogramować klient tak by dało się przekazywać na jego wejście proste polecenia (każde musi się kończyć znakiem końca linii):
  1. CONNECT hostname:port
    • powoduje skonfigurowanie klienta tak by połączył się z serwerem hostname na porcie port
    • hostname - jest nazwą FQDN lub adresem IPv4
    • ip - numer portu podany dziesiętnie
  2. USER username
    • powoduje skonfigurowanie nazwy użytkownika, który będzie odebierał lub wysyłał wiadomości
    • username - jest ciągiem znaków składających się na identyfikator użytkownika
    • GET number
      • pobiera zadaną liczbę wiadomości i wyświetla je na ekran
      • każda wiadomość musi się kończyć dwoma liniami jedną zwierającą kropkę, drugą pustą
      • number - jest dodatnią całkowitą liczbą dziesiętną 
    • POST username
      • wysyła wiadomość do użytkownika username
      • wiadomość ma być wpisywana w kolejnych liniach
      • koniec wpisywania wiadomości oznacza się dwoma liniami - jedną zwierającą kropkę, drugą pustą
    • DISCONNECT
      • powoduje faktyczne rozłączenie klienta z serwerem
      • umożliwia ewentualnie wyspecyfikowanie nowej konfiguracji
    • QUIT
      • kończy działanie klienta
    Każde z wyżej wymienionych poleceń może zwrócić:
    1. OK
      • w przypadku powodzenia, aby zasygnalizować powodzenie
    2. ERROR message
      • kiedy operacja zakończyła się błędem
      • message - jest tekstową reprezentacją błędu
    UWAGA! Jest to minimalny interfejs jaki musi implementować wasz klient.