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

Prezentacja na temat: "QS-Terminal 3000 Prezentacja rozwiązania oraz aspekty techniczne Łukasz Kosson."— Zapis prezentacji:

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

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

3 Co to jest? Rozszerzenie do istniejących aplikacji Q-Line 3000. 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

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

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

6 Architektura Elementy systemu: Klienty Serwer proxy Serwery aplikacji

7 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ć.

8 Architektura

9

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

11 Architektura – w praktyce

12 Technikalia Protokół Bezpieczeństwo Drukowanie Wydajność

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

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

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

16 Bezpieczeństwo – handshake

17 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).

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

19 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.

20 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.

21 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.

22 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ć?

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

24 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

25 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.

26 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.

27 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ć.

28 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ć!

29 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

30 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.

31 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