Next: 7 Wyniki testów Up: Asynchroniczna biblioteka komunikacyjna bez Previous: 5 Przykładowy podsystem komunikacyjny Spis treści
Na potrzeby testowania ZCCL zaprojektowano i zaimplementowano proste, przykładowe aplikacje. Ich napisanie było sprawdzianem, czy używając biblioteki ZCCL można tworzyć w pełni asynchroniczne aplikacje i w związku z tym, czy udało się osiągnąć stawiane ZCCL cele związane z asynchroniczną pracą.
Powstały trzy aplikacje realizujące różne sposoby komunikacji:
Aplikacja ta ma za zadanie sprawdzić szybkość przesyłania komunikatów. Komunikaty są wysyłane w jednym kierunku, od klienta do serwera. Do transmisji używany jest jeden kanał Message.
Po nawiązaniu połączenia, klient wysyła do serwera komunikat zawierający parametry testu. W odpowiedzi serwer wysyła komunikat rozpoczynający test.
Odebranie komunikatu rozpoczynającego test powoduje wysłanie pierwszego komunikatu z danymi. Wysyłanie kolejnych komunikatów odbywa sie kaskadowo. W funkcji obsługi zdarzenia przygotowania komunikatu aplikacja żąda wysłania określonej liczby kolejnych komunikatów. Kaskadowy sposób wysyłania komunikatów przedstawiono na rysunku 6.1.
Kiedy serwer odbierze wszystkie komunikaty z danymi, wysyła komunikat potwierdzający ich odebranie. W momencie odebrania tego komunikatu klient zrywa połączenie.
Działanie aplikacji rozpoczyna się od wywołania funkcji żądania połączenia kanału. Pozostała część działania aplikacji odbywa się w funkcjach obsługi zdarzeń.
Użycie funkcji obsługi zdarzeń do sygnalizacji zdarzeń związanych z połączeniem pozwala w łatwy sposób przedstawić działanie aplikacji w postaci automatu skończonego. Na rysunku 6.2 pokazano diagram stanów dla aplikacji 1way.
Aplikacja pingpong ma za zadanie zmierzyć szybkość odpowiedzi przy przesyłaniu komunikatów. Do transmisji danych używany jest jeden kanał Message.
Po nawiązaniu połączenia, klient wysyła do serwera komunikat zawierający parametry testu. W odpowiedzi serwer wysyła komunikat rozpoczynający test.
Po stronie klienta odebranie komunikatu rozpoczynającego test powoduje wysłanie jednego komunikatu z danymi. Serwer wysyła odpowiedź natychmiast po odebraniu tego komunikatu. Podobnie klient, po odebraniu komunikatu jak najszybciej wysyła odpowiedź. Schemat przesyłania komunikatów jest pokazany na rysunku 6.3.
Klient zrywa połączenie po wysłaniu zadanej liczby komunikatów.
Działanie aplikacji rozpoczyna się od wywołania funkcji żądania połączenia kanału. Pozostała część działania aplikacji odbywa się w funkcjach obsługi zdarzeń.
Diagram stanów połączenia dla aplikacji pingpong pokazano na rysunku 6.4.
Aplikacja post symuluje działanie aplikacji opartej na komunikacji typu żądanie-odpowiedź. Serwer otrzymuje żądania za pomocą kanału Message, a wysyła odpowiedź, w postaci większej ilości danych, za pomocą kanału Post.
W tej aplikacji komunikacja jest bardziej skomplikowana ze względu na to, że używane są dwa kanały.
Po stronie klienta najpierw jest tworzony i podłączany kanał Message, następnie kanał Post. Kiedy oba są połączone, poprzez kanał Message przesyła się komunikat z parametrami testu.
Serwer odbiera ten komunikat i sprawdza, czy kanał Post jest już połączony, czyli czy wywołano już funkcję obsługi zdarzenia połączenia kanału. Jeżeli tak, to wysyła komunikat rozpoczęcia testu. Jeśli nie, to komunikat rozpoczęcia testu zostanie wysłany w funkcji obsługi zdarzenia połączenia kanału.
Taka komplikacja wynika z tego, że klient może otrzymać zdarzenie połączenia kanału, wysłać komunikat z parametrami testu i komunikat ten może zostać odebrany zanim serwer zdąży wywołać funkcję obsługi zdarzenia połączenia kanału dla kanału Post.
Po odebraniu komunikatu rozpoczęcia testu klient żąda wystawienia pewnej liczby buforów. W momencie kiedy bufor zostanie wystawiony, klient wysyła do serwera komunikat z numerem bufora.
Serwer odbiera komunikat z numerem bufora i używając tego numeru wysyła dane poprzez kanał Post.
Kiedy klient odbierze dane, wystawia ponownie bufor i cykl przesyłania zaczyna się od początku.
Schemat wystawiania buforów i przesyłania komunikatów przedstawiono na rysunku 6.5.
Kiedy klient odbierze zadaną liczbę transmisji, zrywa połączenie.
Działanie aplikacji rozpoczyna się od wywołania funkcji żądania połączenia kanału Message. Pozostała część działania aplikacji odbywa się w funkcjach obsługi zdarzeń.
Na rysunku 6.6 pokazano diagram stanów połączenia dla aplikacji post.
Powyższe aplikacje pokazują, że używając ZCCL można tworzyć aplikacje, których całe działanie odbywa się asynchronicznie, w funkcjach obsługi zdarzeń. Do rozpoczęcia działania aplikacji wystarczy wywołać raz funkcję żądania połączenia kanału, a całe działanie aplikacji opiera się na odpowiedniej reakcji na zachodzące następnie zdarzenia. Ponadto stan każdej aplikacji można opisać diagramem stanów, który pozwala w jasny sposób przedstawić jej działanie.
Asynchroniczny model pracy jest bardzo wygodny przy pracy w trybie jądra. Działanie aplikacji w trybie jądra odbywa się w oderwaniu od jakiegokolwiek wątku użytkownika, ponieważ do rozpoczęcia działania aplikacji wystarczy rozpocząć łączenie kanału, a pozostała część działania aplikacji odbywa się w funkcjach obsługi zdarzeń. Możliwe jest więc przekazanie do jądra polecenia rozpoczęcia pracy aplikacji, na przykład poprzez zapisanie odpowiedniej wartości do systemu plików, po czym proces, który wydał to polecenie, może się zakończyć. Aplikacja działa w tym momencie już niezależnie od niego.
Krzysztof Lichota 2002-06-24
