Theoretical scope - document collaboration systems

Thesis/Chapters/1. Theoretical Scope.typ

@@ -1,21 +1,21 @@
+#include "../style.typ"
+
 = Zakres teoretyczny <teoria>
 == Systemy współdzielenia dokumentów w czasie rzeczywistym
-=== Ewentualna zbieżność
-Budując rozwiązania związane z równoczesnym tworzeniem i modyfikacją jakichkolwiek danych przez więcej niż jednego użytkownika, musimy rozważyć mechanizmy zapewniające conajmniej ewentualną zbieżność (eventual consistency), która gwarantuje, że każda kopia danych w naszym systemie będzie identyczna i zawierała najnowszą zmianę u każdego klienta po otrzymaniu wszystkich zdarzeń modyfikujących dane.
+Budując rozwiązania związane z równoczesnym tworzeniem i modyfikacją tekstu przez więcej niż jednego użytkownika, musimy rozważyć wyzwania napotykane w aktualizacji tworzonego dokumentu, gdzie każdy klient posiada lokalną kopię i nanosi na nie własne zmiany, ale też w międzyczasie musimy nanieść zmiany od pozostałych klientów. W takim systemie mówimy wtedy o zbieżności danych@article-eventually_consistent - czyli zapewnieniu tego samego stanu między każdym klientem. W przypadku edycji tekstu skupię się na ewentualnej zbieżności, która uwzględnia posiadanie rozbieżnych kopii tego samego źródła danych u każdego z klientów przez pewien czas. Dopiero gdy zostanie zakończona edycja tekstu, zmiany zostają propagowane i nanoszone do pozostałych klientów. Finalnie każdy klient po czasie posiada identyczną kopię dokumentu. Ze strony doświadczeń użytkowania jest to skuteczna strategia ze względu na możliwość zapewnienia płynności interfejsu graficznego oraz z pomocą złożonych mechanizmów umożliwia rozwiązywanie konfliktów między kopiami.
 
-Popularną strategią w takim podejściu jest Last-Write_wins (LWW). To podejście, gdzie każde otrzymane zdarzenia są ułożone w pewnej kolejności, zazwyczaj opartej o czasie. Rozstrzyga ona konflikty poprzez nanoszenie tylko tej zmiany, która jest uznawana jako ostatnia w kolejności zbioru konfliktujących operacji. Ustalanie kolejności nie jest jasno tutaj zdefiniowane. W systemach baz danych takich jak Cassandra oraz SQL Server P2P każdy zapis otrzymuje własny znacznik czasowy, na podstawie którego wybierany jest najmłodszy wpis i nim nadpisywane są zmiany w źródle danych. Zmiany ze starszymi znacznikami są porzucane. Zauważalną wadą LWW jest wysokie ryzyko utraty danych w czasie nanoszenia zmian, ponieważ wszystkie starsze zmiany nie są brane pod uwagę.
+Wspomniany model nie jest bez wad. Największym problemem jest istnienie konfliktów, których rozwiązanie klienci muszą ustalić za pomocą dodatkowych strategii. Najeczęściej wykorzystywaną jest Last-Write-Wins (LWW). Rozstrzyga ona konflikty poprzez nanoszenie tylko tej zmiany, która jest uznawana jako ostatnia w kolejności zbioru konfliktujących operacji. Ustalanie kolejności nie jest jasno tutaj zdefiniowane. W systemach baz danych takich jak Cassandra@other-apache_cassandra_documentation oraz SQL Server P2P@other-microsoft_sql_server_p2p_replication_documentation każdy zapis otrzymuje własny znacznik czasowy, na podstawie którego wybierany jest najmłodszy wpis i nim nadpisywane są zmiany w źródle danych. Zmiany ze starszymi znacznikami są porzucane. Zauważalną wadą LWW jest wysokie ryzyko utraty danych w czasie nanoszenia zmian, ponieważ wszystkie konfliktujące starsze zmiany nie są brane pod uwagę.
 
-doi:10.1145/1435417.1435432
-https://cassandra.apache.org/doc/latest/cassandra/architecture/dynamo.html#data-versioning
-https://learn.microsoft.com/en-us/sql/relational-databases/replication/transactional/peer-to-peer-transactional-replication?view=sql-server-ver17
-Designing data intensive applications - ISBN	1491903112, 9781491903117
+W przypadku tekstu jako typu danych, istnieje specjalny wariant ewentualnej zbieżności - silna ewentualna zbieżność. Ten model wykorzystuje specjalne struktury danych, które zapewniają bezkonfliktowe nanoszenie zmian, a ich skuteczność opiera się na matematycznych dowodach@article-verifying_strong_eventual_consistency.
 
-=== Silna zbieżność
-W przypadku systemów oferujących współbieżną modyfikację tekstu, gdzie możliwość wystąpienia konfliktów zwiększa się znacząco - przez większą ilość klientów oraz łatwy dostęp do obszarów aktualnie edytowanych przez innych użytkowników - powinniśmy rozważyć mechanizmy silnej zbieżności.
+Istnieje również model silnej zbieżności, gdzie każdy z klientów musi mieć tą samą kopię danych przez cały czas pracy systemu. Ze względu opóźnienia i potrzebę mechanizmu blokady klientów przed wprowadzaniem zmian, ten model został porzucony w dzisiejszych systemach, ponieważ wspomniane problemy skutkowały gorszą użytecznością w porównaniu do systemów wykorzystujących ewentualną zbieżność. Istnieją jednak prace, które wskazują na istnienie systemów opartych o model silnej zbieżności, które osiągają bardzo niskie czasy opóźnienia, co redukuje problem używalności takiego rozwiązania w rzeczywistych zastosowaniach.@other-paxos_document_editor
 
-// === Reprezentacja danych
+== 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.
 
-// === Wygoda użytkowania interfejsu graficznego
+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@other-windowing_in_jupiter, SOCT3/4@other-convergence_in_distributed_real_time_collaborative_environment oraz TTF@other-transformation_functions_consistency_ces. Jupiter oraz SOCT3/4 wymagają wcześniej wspomnianego scentralizowanego serwera. Google Docs początkowo korzystał z Operational Transformation@other-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@other-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@article-replicated_abstract_data_types, WOOT@other-data_consistency_p2p_collaborative_editing oraz TreeDoc@other-commutative_replicated_data_type.
 
 // == Architektura Peer-to-Peer w środowiskach mobilnych
 // == Algorytmy synchronizacji tekstu

Thesis/main.typ

@@ -12,5 +12,8 @@
 #include "table_of_contents.typ"
 #pagebreak()
 
+#zut-template([
   #include "Chapters/1. Theoretical Scope.typ"
+])
+
 #include "Bibliography.typ"