QS-Terminal 3000

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

10. Architektura 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 Nagle’a. • 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ść

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