Sprawozdanie: rzeczy

sprawozdanie/sprawozdanie.tex

@@ -2,33 +2,29 @@
 \usepackage[T1]{fontenc}
 \usepackage{polski}
 \usepackage[utf8]{inputenc}
+\usepackage[polish]{babel}
 \usepackage[margin=1.25in]{geometry}
-\usepackage{alltt}
 \usepackage{titling}
 \usepackage{pdfpages}
 \usepackage{float}
 \usepackage{amsmath}
-\usepackage{booktabs}
-\usepackage{tabularx}
 \usepackage{amstext}
 \usepackage{pgfplots}
 \usepackage{tikz}
-\usepackage{xspace}
 \usepackage{enumerate}
 \usepackage{lmodern}
 \usepackage{amsfonts}
 \usepackage{mathtools}
-\usepackage{alphalph}
 \usepackage{algorithm}
 \usepackage{algpseudocode}
 \usepackage{wrapfig}
-\usepackage[polish]{babel}
 \usepackage{braket}
 \usepackage{subcaption}
 \usepackage{multirow}
 \usepackage{etoolbox}
 \usepackage{color}
 \usepackage{pgfkeys}
+\usepackage{siunitx}
 
 \pgfplotsset{compat=1.15}
 \usepgfplotslibrary{groupplots}
@@ -41,19 +37,41 @@
 \newcommand{\todo}[1]{{\color{blue}\textbf{TODO:} #1}}
 
 \makeatletter
-\newrobustcmd{\member}[3][]{%
-    \ifcsdef{last}{\node[packet, right=of \last, text width=(#3*7.5mm)]}{\node[packet, text width=(#3*7.5mm)]} (#2)
-    {\texttt{#2}};%
-    \node[below=of #2] {#3};
-    \node[above=of #2.north, text depth=0pt] {\texttt{#1}};
-    \def\last{#2}%
-}%
+
 \newenvironment{packet}{%
-    \begin{tikzpicture}[packet/.style={draw, auto, align=center, minimum height=7mm}, node distance=0]%
+    \def\byte{*8mm}%
+
+    \newrobustcmd{\member}[3][]{%
+        \node[packet, minimum width=##3\byte] (##2) {##2};
+        \node[below=of ##2] {##3};
+        \node[above=of ##2.north, text depth=0pt] {##1};
+        
+        \tikzstyle{packet}+=[right=of ##2];
+    }%
+
+    \newrobustcmd{\preamble}[1][15]{%
+        \node[packet, minimum width=2\byte, dashed] (Preamble) {$\cdots$};
+        \node[below=of Preamble] {##1};
+        \node[above=of Preamble.north] {Preambuła};
+        
+        \tikzstyle{packet}+=[right=of Preamble];
+    }%
+
+    \begin{tikzpicture}[%
+        packet/.style={draw, auto, align=center, minimum height=7mm, font=\ttfamily, right=of start},
+        optional/.style={dotted},
+        every node/.style={text depth=0pt},
+        node distance=0,
+        x=8mm, y=1.5cm
+    ]%
+    \node (start) {};
 }{%
     \end{tikzpicture}%
-    \let\last\undefined
+    \let\byte\undefined
+    \let\member\undefined
+    \let\preamble\undefined
 }
+
 \makeatother
 
 % opening
@@ -99,17 +117,16 @@ rozłączy bez konieczności przeprowadzania negocjacji.
 Dodatkowo, przyjmuje się zasadę, że każdy klient jest w 100\% odpowiedzialny za swoją część symulacji, dla której
 stanowi źródło prawdy. tj. każdy gracz wysyła tylko i wyłącznie informacje o zmianach rzeczy, na które on ma wpływ - np.
 pozycję własnego czołgu, czy wystrzelenie pocisku. W gestii innych klientów jest przetworzyć te informację i
-zsynchronizować się. 
+zsynchronizować się. Przewidziano również obiekty o zachowaniu deterministycznym, które każdy klient może aktualizować
+samodzielnie w ramach swojej symulacji.
 
-Takie podejście zapewnia brak konfliktu o zasoby, ponieważ każdy obiekt jest modyfikowany wyłącznie przez jedną osobę (a
-co za tym idzie, jeden wątek) zatem nigdy nie nastąpi wyścig. \todo{Modyfikacja w trakcie odczytu? Ma znaczenie?}
-\areyousure{Przewidziano również wystąpowanie obiektów, które nie posiadają właściciela, a ich zachowanie jest w pełni 
-deterministyczne zatem nie wymaga jawnej synchronizacji pomiędzy klientami.}
+Takie podejście zapewnia brak konfliktu o zasoby, ponieważ każdy obiekt jest modyfikowany wyłącznie przez jedną osobę,
+zatem nigdy nie nastąpi konflikt. Nie występuje również problem odczytywania zmienionych danych ponieważ wyświetlanie
+oraz aktualizacja stanu gry odbywają się w ramach jednego wątku.
 
-Każdy klient będzi obsługiwany przez 5 osobnych wątki, których kompetencje nie kolidują ze sobą:
+Każdy klient będzie obsługiwany przez 4 osobnych wątki, których kompetencje nie kolidują ze sobą:
 \begin{enumerate}
-    \item Renderowanie stanu symulacji
-    \item Aktualizacja stanu (na podstawie kolejki akcji)
+    \item Aktualizacja i renderowanie stanu symulacji  \label{thread:render}
     \item Input z sieci (obiór pakietów, kolejkowanie) \label{input:net}
     \item Input użytkownika (odczyt klawiatury itd.)   \label{input:user}
     \item Output sieciowy (wysyłanie pakietów, retranmisje) \label{output:net}
@@ -121,8 +138,8 @@ kolejki nie zostanie uszkodzony, tj. żadna akcja nie zostanie wykonana 2-krotni
 Zostanie to osiągnięte poprzez ustawienie Mutexa\footnote{https://msdn.microsoft.com/en-us/library/system.threading.mutex(v=vs.110).aspx}
 w metodach.
 
-\areyousure{Zakładamy, że akcje użytkownika muszą zostać zostać umieszczone na kolejce akcji natychmiastowo, zatem nie
-ma potrzeby synchronizacji z siecią.} Co za tym idzie, dostęp do kolejki pakietów (potrzebnej ze względu na możliwość
+Zakładamy, że akcje użytkownika muszą zostać zostać umieszczone na kolejce akcji natychmiastowo, zatem nie
+ma potrzeby synchronizacji z siecią. Co za tym idzie, dostęp do kolejki pakietów (potrzebnej ze względu na możliwość
 otrzymania pakietów w nieodpowiedniej kolejności) i jej obsługa będzie w całości po stronie wątku \ref{input:net} -
 czyli problem wyścigów nie następuje. 
 
@@ -147,18 +164,38 @@ dotarcia pakietów, brak gwarancji kolejności, brak gwarancji poprawności) prz
     \item pakiety mogą wymagać konkretnego poziomu stanu gry
 \end{itemize}
 
+\begin{figure}[H]
+    \centering
+
+    \begin{tikzpicture}[
+        client/.style = { circle, draw },
+        master/.style = { very thick },
+        node distance=2cm
+     ]
+        \node[client, master] (C1) {$C_1$};
+        \node[client, right=of C1] (C2) {$C_2$};
+        \node[client, below=of C2] (C3) {$C_3$};
+        \node[client, left=of C3] (C4) {$C_4$};
+
+        \foreach \u/\v in {C1/C2,C1/C3,C1/C4,C2/C3,C2/C4,C3/C4} \draw[<->] (\u) -- (\v); 
+    \end{tikzpicture}
+
+    \caption{Proponowana architektura sieciowa}
+\end{figure}
+
 Ze względu na konieczność szybkiego przesyłania informacji pomiędzy klientami, zaprojektowany protokół jest protokołem
 binarnym, o konstrukcji pakietu widocznej poniżej.
 
 \begin{figure}[H]
     \center
     \begin{packet}
-        \member{CRC32}{4}
+        \member{CRC16$_p$}{2}
         \member{Type}{1}
         \member{Size}{2}
         \member{ClientId}{2}
         \member{State}{4}
         \member{PacketId}{4}
+        \node[packet, dashed, right=of PacketId, text width=15mm] {CRC16$_d$};
     \end{packet}
 
     \caption{Preambuła pakietu} 
@@ -168,12 +205,13 @@ binarnym, o konstrukcji pakietu widocznej poniżej.
     \centering
     \begin{tabular}{l|l|l}
         \textbf{Właściwość} & \textbf{Typ} & \textbf{Opis} \\ \hline
-        \texttt{CRC32} & \texttt{int32} & Suma kontrolna danych w pakiecie \\
+        \texttt{CRC16$_p$} & \texttt{int16} & Suma kontrolna danych w preambule \\
         \texttt{Type} & \texttt{uint8}  & Rodzaj wysyłanego pakietu \\ 
         \texttt{Size} & \texttt{uint16} & Rozmiar wysłanych danych, razem z pierwszym bajtem \\
         \texttt{ClientId} & \texttt{uint16} & Identyfikator klienta \\
         \texttt{State} & \texttt{uint32} & Wymagany stan gry do przetworzenia pakietu \\
-        \texttt{PacketId} & \texttt{uint32} & Timestamp oryginalnego wysłania pakietu
+        \texttt{PacketId} & \texttt{uint32} & Timestamp oryginalnego wysłania pakietu \\ \hline
+        \texttt{CRC16$_d$} & \texttt{int16} & Suma kontrolna danych pakietu (o ile jakieś są) \\
     \end{tabular}
 \end{table}
 
@@ -190,7 +228,7 @@ W wypadku niezgodności przesłanej sumy kontrolnej z sumą wyliczoną po stroni
 \texttt{RET = 0x81}. Dla pakietów mało ważnych nie zachodzi potrzeba retransmisji. 
 
 Aby upewnić się, że transmisja ważnego pakietu się powiodła, każdy klient musi odpowiedzieć pakietem \texttt{ACK}
-(\texttt{Type = 0x80}). W wypadku, gdyby odpowiedź \texttt{ACK} nie dotarła w ciągu $t \text{ms}$ pakiet zostaje
+(\texttt{Type = 0x80}). W wypadku, gdyby odpowiedź \texttt{ACK} nie dotarła w ciągu $t\ \si{ms}$ pakiet zostaje
 wysłany ponownie. 
 
 W przypadku wielokrotnego otrzymania pakietu o tym samym \texttt{PacketId} (np. w wypadku automatycznej retramsnisji),
@@ -204,9 +242,9 @@ wzgledu na to, że \texttt{ACK} nie jest bezpośrednio związany z rozgrywką, w
 \begin{figure}[H]
     \center
     \begin{packet}
-        \member{CRC32}{4}
+        \member{CRC16$_p$}{2}
         \member[Type]{0x80}{1}
-        \member[Size]{17}{2}
+        \member[Size]{15}{2}
         \member{ClientId}{2}
         \member[State]{0}{4}
         \member{PacketId}{4}
@@ -215,6 +253,15 @@ wzgledu na to, że \texttt{ACK} nie jest bezpośrednio związany z rozgrywką, w
     \caption{Pakiet \texttt{ACK}} 
 \end{figure}
 
+\subsection{Zestawienie połączeń}
+Ze względu na to, że port na którym nasłuchują klienci nie jest deterministyczny istnieje konieczność wprowadzania
+scentralizowanego \textit{lobby} pozwalającego na wymianę tych informacji pomiędzy klientami. Jedynym zadaniem
+\textit{lobby} jest przechowywanie informacji o graczach chcących wspólnie zagrać, zatem nie zachodzi potrzeba szybkiego
+działania. 
+
+Stąd przyjęto, że do realizacji lobby zostanie wykorzystany protokół TCP. Ze względu na to, że lobby stanowi jedynie
+pośrednika do zestawiania połączeń, dokładny opis działania zdecydowano się pominąć.
+
 \section{Rozwiązania}
 O nie w tym wypadku też ciężko