QS-Terminal 3000 Prezentacja rozwiązania oraz aspekty techniczne Łukasz Kosson

Plan prezentacji O rozwiązaniu: Co? Po co? Dla kogo? Wnętrzności: Komunikacja Grafika Wydajność

Co to jest? Rozszerzenie do istniejących aplikacji Q-Line Dostosowane do SCMa. Rozwiązanie nieinwazyjne. Jak ViaNet, ale: Wymaga małego programu klienckiego Nie wymaga zmian w aplikacji Wygodniejsza obsługa Większe wymagania co do serwera

Co to potrafi? Tunelowanie zdarzeń i grafiki. Tunelowanie wydruków. Całkowita niezależność klienta od Q-Line Bardzo mały rozmiar klienta (~30kb)

Do czego się może przydać? Praca z domu. Stacje robocze bezdyskowe. Wersja demo jako applet.

Architektura Elementy systemu: Klienty Serwer proxy Serwery aplikacji

Architektura Założenia: Klienty i serwery łączą się z serwerem proxy. Jeden fizyczny serwer aplikacji może uruchomić dowolną ilość instancji dowolnego programu. Klienty i serwery mogą się łączyć przez dowolną sieć.

Architektura

W praktyce: Serwery aplikacji i serwer proxy są uruchomione na tej samej fizycznej maszynie. Klienty łączą się przez Internet.

Architektura – w praktyce

Technikalia Protokół Bezpieczeństwo Drukowanie Wydajność

Protokół Komunikacja TCP. Własne mechanizmy serializacji. Grupowanie komunikatów. Kompresja GZIP w locie.

Komunikacja TCP Jedno połączenie = jedna sesja. Algorytm Naglea. Selectory i NIO w Javie.

Bezpieczeństwo Handshake z proxy. Identyfikator klienta. Klucz prywatny (wspólny). Klucz sesyjny. Kodowanie.

Bezpieczeństwo – handshake

Bezpieczeństwo Za wyjątkiem pierwszego komunikatu, cała komunikacja jest szyfrowana. Szyfrowanie strumieniowe LFSR. Wymogi czasowe na handshake. Błąd protokołu = rozłączenie. W przypadku kradzieży klucza, można łatwo zablokować dostęp. Wymuszenie uczciwości (licencje).

Serializacja Zwykła. Operuje na prymitywach i tablicach. Obcinanie wartości: (int)10 = (byte)10 (long)255 = (short)255

Grafika Jak to działa w SCM? Komponent zgłasza NeedPaint Root dodaje zgłoszony obszar do obszaru do odrysowania. Worker thread rozpoczyna rysowanie zgłoszonego obszaru. Po zakończeniu odrysowania, w miejsce zgłoszonego obszaru jest wstawiana nowa wartość. Rysowanie realizowane do backbuffera.

Grafika Pomysł: Stwórzymy własnego qline.scm.Graphics, który zamiast rysować, będzie wysyłał informacje o operacjach do klienta. Klient u siebie będzie wykonywał stosowne operacje tak, jak ScreenGraphics do tej pory.

Grafika Sytuacja: Oglądam RecEdit. StringEdit co 0.5 sekundy miga kursorem. Idzie NeedPaint do RootComponenta z prośbą o odrysowanie obszaru o rozmiarze 2x15 px.

Grafika Sytuacja: Oglądam RecEdit. StringEdit co 0.5 sekundy miga kursorem. Idzie NeedPaint do RootComponenta z prośbą o odrysowanie obszaru o rozmiarze 2x15 px. Problem: Jakie operacje graficzne powinienem przesłać?

Grafika Możliwości: Wszystko jak leci. Tylko to, co pokrywa się z odrysowanym obszarem. Tylko to, co ma wpływ na wynikowy obraz.

Grafika Możliwości: Wszystko jak leci. Tylko to, co pokrywa się z odrysowanym obszarem. Tylko to, co ma wpływ na wynikowy obraz. Pomysł: Połączenie powyższych metod

Grafika Rozwiązanie: Na początku rysowania tworzymy bitmapę o rozmiarze takim, jak rysowany obszar. Dla każdej operacji sprawdzamy, czy jej kawałek pokrywa się z rysowanym obszarem. Jeśli nie, to ją pomijamy. Wykonujemy operację na bitmapie, ale innym (unikalnym) kolorem. Zapisujemy wykonaną operację na liście wraz z informacją o oryginalnym kolorze, czcionce, clippingu i kolorze użytym powyżej.

Grafika Rozwiązanie, cd: Po zakończeniu rysowania sprawdzamy, jakie kolory znalazły się na bitmapie. Odtwarzamy operacje z listy i filtrujemy te, których koloru nie znaleźliśmy na bitmapie. Efekt: Mamy listę operacji, które faktycznie mają wpływ na wynikowy obraz. Dla każdej z nich budujemy komunikat. Wszystkie komunikaty sklejamy w jeden duży, kompresujemy i wysyłamy.

Drukowanie Idea: Przecież drukowanie to takie rysowanie, ale na karce a nie na monitorze. Rozwiązanie: Wykorzystujemy tę samą klasę, co do rysowania po ekranie. Problemy: Co z okienkiem, które prosi o wybranie drukarki, papieru, itp? Nie możemy jednocześnie rysować i drukować.

Drukowanie Idea: Przecież drukowanie to takie rysowanie, ale na karce a nie na monitorze. Rozwiązanie: Wykorzystujemy tę samą klasę, co do rysowania po ekranie. Problemy: Co z okienkiem, które prosi o wybranie drukarki, papieru, itp? Wyświetlamy je modalnie po stronie klienta i przesyłamy odpowiedź. Nie możemy jednocześnie rysować i drukować. Przecież nie chcemy jednocześnie rysować i drukować!

Wydajność Ekran statyczny (browser, menu, podgląd wydruku)0 kb/s RecEdit, migający kursor0,1 kb/s Bardzo szybkie wpisywanie tekstu3 kb/s Chodzenie po browserze3 kb/s Skakanie po browserze8 kb/s Skakanie po aplikacji, zmiana layoutu10 kb/s Otwarcie RecEdita, Browsera, podglądu wydruku~ 20kb Drukowanie~ 10kb / str. Opóźnienie w komunikacji~ 5 ms Opóźnienie w komunikacji (kompresja i łączenie wiadomości)~ 50 ms

Wydajność Konfiguracja: Przesyłanie obrazków. Kompresja obrazków. Z-buforowanie. Pomijanie mało istotnych operacji. Kompresja danych. Opóźnienie wysyłania zdarzeń od klienta.

Czas Bo wielu się pytało – ile czasu to zajęło: Proof of concept, ~ 5h Działająca alfa, ~ 10h Debugowanie, ~ 20h Serwer proxy, ~ 10h Bezpieczeństwo, ~ 2h Wydruki, ~ 5h Podłączenie drugiej aplikacji, ~ 5 min