diff --git a/Thesis/.zed/settings.json b/Thesis/.zed/settings.json new file mode 100644 index 0000000..3609f80 --- /dev/null +++ b/Thesis/.zed/settings.json @@ -0,0 +1,4 @@ +{ + "soft_wrap": "editor_width", + "project_name": "Praca dyplomowa inżynierska" +} diff --git a/Thesis/Chapters/1. Theoretical Scope.typ b/Thesis/Chapters/1. Theoretical Scope.typ index a89f1af..e1b6244 100644 --- a/Thesis/Chapters/1. Theoretical Scope.typ +++ b/Thesis/Chapters/1. Theoretical Scope.typ @@ -1,11 +1,28 @@ = Zakres teoretyczny == Systemy współdzielenia dokumentów w czasie rzeczywistym -== Architektura Peer-to-Peer w środowiskach mobilnych -== Algorytmy synchronizacji tekstu -== Frameworki sieciowe udostępniane na platformach Apple -=== Multipeer Connectivity -=== Network -== Analiza istniejących rozwiązań -=== Aplikacje zcentralizowane -=== Aplikacje zdecentralizowane -=== Problemy w istniejących rozwiązaniach +=== 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. + +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ę. + +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 + +=== 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. + +// === Reprezentacja danych + +// === Wygoda użytkowania interfejsu graficznego + +// == Architektura Peer-to-Peer w środowiskach mobilnych +// == Algorytmy synchronizacji tekstu +// == Frameworki sieciowe udostępniane na platformach Apple +// === Multipeer Connectivity +// === Network +// == Analiza istniejących rozwiązań +// === Aplikacje zcentralizowane +// === Aplikacje zdecentralizowane +// === Problemy w istniejących rozwiązaniach diff --git a/Thesis/main.pdf b/Thesis/main.pdf index 3a330be..f57500a 100644 --- a/Thesis/main.pdf +++ b/Thesis/main.pdf @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:977101f53b2de80b14de8b975c46406ab78531a9f0d66856bf9f524d4550b5a7 -size 49591 +oid sha256:0c5f0a9d5e0d09add29d1dbdeeb3fa1d328b9324c4f2535df1decce4b11c93ed +size 77354 diff --git a/Thesis/main.typ b/Thesis/main.typ index 16a4799..1e2dc25 100644 --- a/Thesis/main.typ +++ b/Thesis/main.typ @@ -1,7 +1,9 @@ #import "style.typ": definition, example, theorem, zut-template #include "title_page.typ" - #pagebreak(to: "odd") #include "table_of_contents.typ" +#pagebreak() + +#include "Chapters/1. Theoretical Scope.typ"