Diagram komponentów
jAgE Component - klient CS, wysyła i odbiera wiadomości posługując się interfejsami IMessageListener i ICommunicationService.
CommunicationService - główny komponent, jego cykl życia jest kontrolowany prze jAgE za pośrednictwem interfejsu IPlatformComponent.
Diagram klas
CommunicationService
ClassPropertyContainer - klasa rozszerzana przez CS w celu umożliwienia ustawiania wartości atrybutów w pliku konfiguracyjnym.
ICommunicationService - interfejs komunikacyjny.
IPlatformComponent - interfejs kontrolujący cykl życia komponenty platformy jAgE.
IComponentEnvironment - CS uzyskuje przez ten interfejs logiczny adres węzła i referencje na komponenty-klientów.
INodeConnector - interfejs zdalny pozwalający przesyłać dane pomiędzy różnymi CS.
IAddressMapper - odpowiada za mapowanie adresów logicznych na fizyczne węzły. Zbiera i przechowuje informacje o stanie innych węzłów, wyszukuje INodeConnector wymagane do przesłania danych.
IClientBuffer - odpowiada za rozdysponowanie otrzymanej wiadomości do odbiorców, przechowuje wiadomości jeśli zajdzie taka konieczność.
IBuffer - odpowiedzialny za agregowanie wiadomości przed wysłanie na docelowy węzeł.
CS jest thread safety.
AddressMapper
NodeRegister -przechowuje informacje o rmiregistry dotyczącą NodeConnector znanych węzłów, używany jest też do przekazywania informacji o węzłach do nowo uruchomionych CS.
NodeInfo - klasa przechowująca informacje w węzłach, jego adres, status, NodeRegistry i na potrzeby inicjalizacji selektorów ComponentAddress reprezentujący dany węzeł.
NodeStatus - typ wyliczeniowy określający stan węzła.
Diagram sekwencji
Start komponentu
SC jest uruchamiany przez jAgE, przed uruchomieniem mappera NodeConnector jest już wyeksportowany (może odbierać wiadomości z innych CS) i dowiązany do rmiregistry (inne CS mogą uzyskać do tego NodeConnectora referencje). CS uruchamia własny watek który obsługuje wiadomości, motywacją ku temu było to, że zmniejsza to problemy z synchronizacją, rmi siłą rzeczy wykorzystuje sieć a wiec operacje blokujące - w tej sytuacji osobny wątek jest bardziej efektywny z perspektywy węzła. Ostatnim powodem była chęć wprowadzenia czasowych ograniczeń na wysyłanie wiadomości (Usypianie wątku na określony czas).
Start mappera
Na początku jest uruchamiany wątek nasłuchujący pakietów hello, po czym rozsyłane są własne pakiety hello.
Pakiety hello rozsyłane są poprzez UDP na grupę multicastową podaną w konfiguracji (grupa i port).
Budowa pakietu hello:
pole |
typ |
opis |
|---|---|---|
1 |
String |
logiczny adres węzła |
2 |
String |
adres IP rmiregistry z którym jest związany NodeConnector tego CS |
3 |
int |
port na którym jest dostępne rmiregistry |
4 |
int |
licznik, określający który to jest pakiet hello |
5 |
int |
flaga, określająca czy CS wysyłający pakiet hello otrzymał już informacje o innych węzłach |
W momencie kiedy do CS dotrze pakiet hello z licznikiem równym ilości pakietów hello podanej w konfiguracji, taki CS przekazuje nowemu węzłowi informacje o wszystkich znanych mu i działających węzłach.
Wysyłanie wiadomości
W wątku klienta odbywa się sprawdzenie poprawności nagłówka, serializacja "treści", odłożenie przygotowanej wiadomości do innerQueue, po czym notyfikowany jest główny wątek CS (CommunicationThread – CT) i funkcja powraca.Dzięki innerQueue można wywoływać metodę send na nie zainicjowanym CS, pojemność kolejki wynosi Integer.MAX_VALUE wiadomości, przekroczenie tej wartości zawiesi watek klienta aż do pełnej inicjalizacji CS. CT w ramach swojej działalności pobiera wszystkie wiadomości z innerQueue, przekazując je do bufora agregującego. Z bufora agregującego pobierane są wszystkie pakiety, czyli zgrupowane zbiory wiadomości do wysłania do konkretnego węzła, spełniające kryteria wysłania.
Kryteria wysłania:
- Minimalna pojemność - gdy wielkość wiadomości w pakiecie przekroczy daną wartość
- Maksymalny czas - jeśli jakakolwiek wiadomość w pakiecie przekroczy dany maksymalny czas oczekiwania na wysłanie - nie zaimplementowane
CT podejmuje próbę wysłania pakietu, w razie niepowodzenia wiadomość wraca do bufora agregującego i zwiększany jest licznik''nieudanych prób'' dla danego węzła, gdy licznik ten przekroczy zdaną wartość, węzeł uznawany jest za martwy. CT odrzuca pakiety skierowane do martwych węzłów.
Odbieranie wiadomości
Zadanie NodeConnectora sprowadza się do odebrana pakietu i dla każdej zawartej tam wiadomości odtworzenia nagłówka z nadawcą i odbiorcą. Wiadomości trafiają do bufora klientów gdzie są dostarczone do odbiorcy lub oczekują aż klient się po nie zgłosi.
Attachments:
klas.png (image/png)
start_maper.png (image/png)
start.png (image/png)
components.png (image/png)
klas_mapper.png (image/png)
recive.png (image/png)
send.png (image/png)