diff --git a/Thesis/Chapters/1. Theoretical Scope.typ b/Thesis/Chapters/1. Theoretical Scope.typ index 9788d0a..33c21c6 100644 --- a/Thesis/Chapters/1. Theoretical Scope.typ +++ b/Thesis/Chapters/1. Theoretical Scope.typ @@ -13,7 +13,7 @@ Istnieje również model silnej zbieżności, gdzie każdy z klientów musi mie == Algorytmy zapewniające silną ewentualną zbieżność Podejście do rozwiązania problemu synchronizacji stanów między każdym klientem wymaga zaprojektowania algorytmu od podstaw skupionego na tym zagadnieniu. Przedstawię dwa najczęściej wykorzystywane algorytmy rozwiązujące opisany problem. -Operational Transformation (OT) polega na zamianie każdej wykonanej operacji na kodowalny obiekt, który może być propagowany i nanoszony na kopie w innych replikach. Większość znanych implementacji zakłada też, że istnieje scentralizowany serwer określający kolejność każdej operacji zgłaszanej przez wszystkich klientów i dystrybujący wspomniane zmiany do pozostałych replik. W przypadku wystąpienia konfliktu, operacje są sortowane przez serwer, a następnie każda z nich jest transformowana tak, by uwzględnić zmianę poprzedniej w kolejności operacji. Przykładowymi propozycjami algorytmów OT, których skuteczność nie została obalona dowodami, są: Jupiter@cite:windowing_in_jupiter, SOCT3/4@cite:convergence_in_distributed_real_time_collaborative_environment oraz TTF@cite:transformation_functions_consistency_ces. Jupiter oraz SOCT3/4 wymagają wcześniej wspomnianego scentralizowanego serwera. Google Docs początkowo korzystał z Operational Transformation@cite:google_docs_ot. Ze względu na złożność implementacji większość systemów nie korzysta dziś z tych algorytmów do synchronizacji danych, gdzie przykładem takiej decyzji jest Figma@cite:figma_multiplayer. +Operational Transformation (OT) polega na zamianie każdej wykonanej operacji na kodowalny obiekt, który może być propagowany i nanoszony na kopie w innych replikach. Większość znanych implementacji zakłada też, że istnieje scentralizowany serwer określający kolejność każdej operacji zgłaszanej przez wszystkich klientów i dystrybujący wspomniane zmiany do pozostałych replik. W przypadku wystąpienia konfliktu, operacje są sortowane przez serwer, a następnie każda z nich jest transformowana tak, by uwzględnić zmianę poprzedniej w kolejności operacji. Przykładowymi propozycjami algorytmów OT, których skuteczność nie została obalona dowodami, są: Jupiter@cite:windowing_in_jupiter, SOCT3/4@cite:convergence_in_distributed_real_time_collaborative_environment oraz TTF@cite:transformation_functions_consistency_ces. Jupiter oraz SOCT3/4 wymagają wcześniej wspomnianego scentralizowanego serwera. Google Docs opiera się na Operational Transformation@cite:google_docs_ot. Ze względu na złożność implementacji większość systemów nie korzysta dziś z tych algorytmów do synchronizacji danych, gdzie przykładem takiej decyzji jest Figma@cite:figma_multiplayer. Następcą Operational Transformation są bezkonfliktowe replikowane typy danych (Conflict-free replicated data types - CRDT). Pozwalają one na nanoszenie zmian na własne kopie przez klientów, bez potrzeby uzgadniania tego z innymi klientami. Tak jak każdy algorytm ewentualnej zbieżńości, pozwala na tymczasową rozbieżność między replikami, ale po otrzymaniu wszystkich zmian przez każdego klienta, dane zawsze pozostają zbieżne. Przykładowymi algorytmami są RGA@cite:replicated_abstract_data_types, WOOT@cite:data_consistency_p2p_collaborative_editing oraz TreeDoc@cite:commutative_replicated_data_type. @@ -37,7 +37,7 @@ Network jest frameworkiem skupionym na ogólnej interakcji z połączeniami siec W przypadku oparcia aplikacji komunikujacej się peer to peer z innymi urządzeniami o Network, musimy przygotować własny protokół ramkowania `NWProtocolFramerImplementation`. W nim powinniśmy obsłużyć wszystkie wydarzenia związane z poprawnym zarządzaniem połączeniem - inicjację, powrót z uśpienia, zatrzymanie, proces czyszczenia prze dealokacją. Do nasłuchiwania na przychodzące połączenia wykorzystalibyśmy obiekt `NWListener`. Połączenie z innymi urządzeniem byłoby reprezentowane przez obiekt `NWConnection`, a jeśli chcielibyśmy zaimplementować własny proces odkrywania i negocjacji połączenia z pobliskimi urządzeniami, musielibyśmy dodatkowo wykorzystać obiekt `NWBrowser`. -// == Analiza istniejących rozwiązań -// === Aplikacje zcentralizowane -// === Aplikacje zdecentralizowane -// === Problemy w istniejących rozwiązaniach +== Istniejące rozwiązania i ich problemy +Dwoma najpopularniejszymi aplikacjami do współtworzenia notatek w czasie rzeczywistym są Google Docs i Microsoft Word Online. Ich zakres funkcjonalności jest bardzo podobny - złożone formatowanie tekstu; możliwość dodawania załączników, tabel; historia wersji dokumentu; obecność publicznego API; wykorzystanie nowoczesnych standardów szyfrowania komunikacji; eksport dokumentu w postaci innego rodzaju pliku oraz wymagają konta do możliwości ich użycia. Google Docs korzysta ze swojego algorytmu Operational Transformation do synchronizacji zmian między użytkownikami, sposób przechowywania dokumentów nie jest jasny, nie wiemy w jakiej postaci są one przechowywane na serwerach Google, a dostęp do aplikacji jest darmowy. Microsoft Word Online nie udostępnia publicznie informacji o stosowanym podejściu do synchronizacji danych, dokumenty są przechowywane w postaci plików docx, a dostęp do aplikacji jest również darmowy. + +Głównym problemem większości dzisiejszych narzędzi do tworzenia dokumentów jest uzależnienie od dostawcy. Każda z wymienionych aplikacji, jak i wiele innych dostępnych na rynku do skorzystania ze swoich usług wymaga założenia konta na platformie dostawcy, a w czasie współpracy wymagany jest ciągły dostęp do Internetu. W momencie gdy pracujemy nad jednym dokumentem z innymi użytkownikami w tym samym pomieszczeniu i nasze urządzenia są podłączone do tej samej sieci, opóźnienie w nanoszeniu zmian między użytkownikami zawsze uwzględnia dostęp do scentralizowanych serwerów. W momencie gdy zostaniemy odcięci od dostępu do Internetu, ale nadal będąc w tej samej sieci lokalnej, tracimy możliwość dalszej pracy. Szczególnie widać to w przypadku Google Docs, którego algorytm synchronizujący narzuca obecność serwera wybierającego kolejność nanoszenia zmian w dokumentach. \ No newline at end of file diff --git a/Thesis/Chapters/2. Requirements.typ b/Thesis/Chapters/2. Requirements.typ index a1c8d89..d07b707 100644 --- a/Thesis/Chapters/2. Requirements.typ +++ b/Thesis/Chapters/2. Requirements.typ @@ -1,5 +1,5 @@ = Wymagania systemowe == Wymagania funkcjonalne == Wymagania niefunkcjonalne -=== Wydajność i skalowalność -=== Bezpieczeństwo i prywatność (szyfrowanie end-to-end) \ No newline at end of file +== Wydajność i skalowalność +== Bezpieczeństwo i prywatność \ No newline at end of file diff --git a/Thesis/Chapters/3. Implementation.typ b/Thesis/Chapters/3. Implementation.typ index a89e36d..7ebcaf2 100644 --- a/Thesis/Chapters/3. Implementation.typ +++ b/Thesis/Chapters/3. Implementation.typ @@ -1,12 +1,12 @@ = Implementacja == Projekt architektury systemu -=== Model danych -=== Warstwa sieciowa i komunikacja P2P -=== Odkrywanie innych urządzeń -=== Transportowanie danych -=== Algorytm rozwiązywania konfliktów -=== Środowisko developerskie i stack technologiczny -=== Implementacja logiki P2P -=== Interfejs użytkownika -=== Napotkane wyzwania implementacyjne i rozwiązania -=== Ograniczenia środowisk iOS/macOS +== Model danych +== Warstwa sieciowa i komunikacja P2P +== Odkrywanie innych urządzeń +== Transportowanie danych +== Algorytm rozwiązywania konfliktów +== Środowisko developerskie i stack technologiczny +== Implementacja logiki P2P +== Interfejs użytkownika +== Napotkane wyzwania implementacyjne i rozwiązania +== Ograniczenia środowisk iOS/macOS diff --git a/Thesis/main.pdf b/Thesis/main.pdf index 9c7b9ec..3658900 100644 --- a/Thesis/main.pdf +++ b/Thesis/main.pdf @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:779527747e84a9efe13bda902424d214e7e5e934851e1ae16c5f9ee820ff67af -size 161474 +oid sha256:4fc3594dd4f5e5c2727252a79532a5bcc54c04215abd36912e2617289b27e36c +size 225083 diff --git a/Thesis/main.typ b/Thesis/main.typ index cf4add8..a5bb1d4 100644 --- a/Thesis/main.typ +++ b/Thesis/main.typ @@ -12,6 +12,10 @@ #zut-template([ #include "Chapters/1. Theoretical Scope.typ" + #include "Chapters/2. Requirements.typ" + #include "Chapters/3. Implementation.typ" + #include "Chapters/4. Tests.typ" + #include "Chapters/5. Summary.typ" ]) #render-bib()