Implementacja rozproszonego systemu monitorującego i przewidującego stan sieci: węzłów (komputerów) i połączeń pomiędzy nimi.
System powinien zbierać dane korzystając z sensorów różnego typu, mierzących parametery takie jak np. chwilowe użycie procesora i pamięci, temperatura procesora, ale również dostępna przepustowość sieci i opóźnienia (latency), mierzone metodą end-to-end, pomiędzy dwoma węzłami należącymi do naszej sieci.
Dane z sensorów powinny być agregowane i wysyłane do składnic danych, z których z kolei korzystać będą moduły wizualizacji aktualnego stanu sieci i przewidywania przyszłego stanu (w oparciu o modele statystyczne, bądź skonstruowane przez algorytmy maszynowego uczenia się). Moduł przewidywania powinien udostępniać wyniki analiz poprzez SOAP. Moduł wizualizacji powinien udostępniać wykresy i schematy poprzez www (interfejsem jest przegladarka).
System powinien być maksymalnie rozproszony, działający na zasadzie P2P. Każdy sensor powinien mieć możliwość rejestracji kilku składnic danych, które deklarują chęć powiadamiania o nowych danych. Składnice danych powinny wymieniać dane pomiędzy sobą, tak, żeby każda miała jak najbardziej kompletny opis systemu. Moduły wizualizacji i przewidywania również powinny mieć możliwość korzystania z wielu składnic jednoczesnie (nie możemy założyć, że każda składnica ma wszystkie dane). Z drugiej strony należy uniknąć nadmiarowych transferów danych.
Proszę o zaimplementowanie systemu w Javie (1.5), Pythonie i/lub C++. Każdy ze składników systemu powinien działać na co najmniej na dwóch systemach operacyjnych: Linuksie (zakładamy w miarę nowoczesne jądro z serii 2.6.x) i Windows XP. System powinien umieć wymieniać dane pomiędzy hostami o różnych systemach operacyjnych. W Javie można rozważyć skorzystanie z biblioteki JXTA. Moduł wizualizacji może być zaimplementowany jako servlet lub strona www np. w JSP.
Sugeruję zespół 2 osobowy (i max. 2 osobowy). Po wybraniu tego projektu proszę o kontakt mailowy ( krz@pjwstk.edu.pl ) w celu doprecyzowania szczegółów.
Implementacja rozproszonego systemu wykonywania obliczeń w sieciach P2P.
Systemy wykorzystujące moc obliczeniową nieużywanych komputerów pierwszej generacji (seti@home i spadkobiercy) zakładają centralizację systemu (wszyscy liczą fragment jednego z kilku zadań wybranych przez autorów aplikacji) i liczenie w trybie best-effort (obliczenia są przerywane, gdy tylko użytkownik zaczyna potrzebować mocy obliczeniowej). W tym zadaniu proszę o zaimplementowanie systemu rozproszonego i gwarantującego czas ukończenia przesłanych zadań.
Zakładamy, że każdy użytkownik, który podłącza swój komputer do systemu, ma możliwość wysyłania swoich zadań do obliczenia. Abstrakcyjne "zadanie" może być albo divisible load, albo rigid task, może być preemptive albo nie-preemptive i może być liczone albo wewnątrz Javy, albo przez jeden z kilku programów zewnętrznych (np. povray). Nie dopuszczamy zadań, które wymagają równoległego wykonania na kilku komputerach. Dla uproszczenia można założyć, że na maszynie może być wykonywane jednocześnie tylko jedno zadanie (tzn. maszyna ma jeden procesor) -- choć proszę przygotować system tak, by zmiana tego założenia nie wymagała zbyt dużych zmian.
Zakładamy, że użytkownik, wysyłając zadanie, wie jak "ciężkie" jest to zadanie, a z kolei każda maszyna zna swoją prędkość przetwarzania. Każdy użytkownik wysyła swoje zadania do lokalnego RMS (Resource Management System). Zakładamy, że RMS ma pełną kontrolę nad lokalną maszyną -- wie o wszystkich zadaniach które się wykonują i które będą wykonywane w przyszłości (o ile zostały już wysłane do systemu).
RMSy z poszczególnych maszyn mogą się komunikować ze sobą w celu wyrównania obciążenia (load balancing). Odbywa się to poprzez przesłanie zadań, lub ich fragmentów (gdy zadanie jest typu divisible load) pomiędzy maszynami. Trzeba się zastanowić, co zrobić, by load balancing był opłacalny dla wszystkich uczestniczących węzłów -- tu proszę umożliwić implementację kilku algorytmów load-balancingu, które można byłoby zmieniać.
Istotną częścią wstępnej fazy projektu jest właściwe zamodelowanie tej sytuacji w formie diagramów UML: klas i czynności/sekwencji.
Proszę o zaimplementowanie tego systemu w Javie i z wykorzystaniem biblioteki JXTA.
Sugeruję zespół 2-3 osobowy (i max. 3 osobowy). Po wybraniu tego projektu proszę o kontakt mailowy ( krz@pjwstk.edu.pl ) w celu doprecyzowania szczegółów.
Implementacja rozproszonego systemu proxy anonimizującego połączenia http, czyli "następnym razem, gdy będziesz wysyłał komuś pogróżki z kawiarni internetowej, nie daj się złapać!".
Najprostsza implementacja anonimizera http składa się z dwóch części: lokalnego "serwera" proxy (działającego na tej samej maszynie co przeglądarka) i jednego lub więcej serwerów-anonimizerow. Przegladarka łączy się z lokalnym proxy. Proxy zna adresy kilku anonimizerów (np. A1,..., A7). Przy każdym połączeniu http, proxy generuje losową kolejność kilku lub wszystkich anonimizerów (np. A5->A3->A2->A7), i wysyła zaszyfrowaną (kryptografia asymetryczna) paczkę (dane + kolejność anonimizerów) do pierwszego serwera. Pierwszy z serwerów deszyfruje dane, usuwa siebie z listy serwerów, szyfruje dane kluczem drugiego serwera i wysyła do niego zaszyfrowaną paczkę. Dane są w ten sposób przekazywane pomiędzy serwerami z listy. Ostatni z serwerów wysyła oryginalne żądanie HTTP do oryginalnego serwera. Odpowiedź przechodzi podobną drogę. Dzięki temu oryginalny serwer widzi tylko adres ostatniego serwera. Zakładając, że anonimizery nie przechowują logów, pozwala to na ukrycie prawdziwej tożsamości oryginalnego użytkownika, zarówno przed docelowym serwerem (ten widzi adres ostatniego anonimizera), jak i ISP użytkownika (bo dane, które on może podejrzeć, są szyfrowane). Gdy anonimizerów jest kilka, skompromitowanie nawet części z nich (np. nagłą rewizją policyjną), pozwala zachować pełną anonimowość użytkowników.
Proszę o zaimplementowanie tego typu anonimizera w Javie. Sugeruję zespół 2 osobowy (i max. 2 osobowy). Projekt powinien zawierać implementację lokalnego proxy i serwerów anonimizerów. Po wybraniu tego projektu proszę o kontakt mailowy ( krz@pjwstk.edu.pl ) w celu doprecyzowania szczegółów.
[adres_ip_terminala] [domena z którą ten terminal może się połączyć]Np. jeśli terminal 192.168.1.5 ma łączyć się tylko z francuskim dziennikiem "Le Monde", a terminal 192.168.1.6 z hiszpańskim "El Pais", plik konfiguracyjny wygląda następująco:
192.168.1.5 http://www.lemonde.fr 192.168.1.6 http://www.elpais.es