From bcd17576bb3d7ca85802400584778f809448c327 Mon Sep 17 00:00:00 2001
From: Kacper Donat <kadet1090@gmail.com>
Date: Sat, 14 Apr 2018 12:05:33 +0200
Subject: [PATCH] Sprawozdanie: ACK i RET

---
 sprawozdanie/sprawozdanie.tex | 53 +++++++++++++++++++++++++++--------
 1 file changed, 42 insertions(+), 11 deletions(-)

diff --git a/sprawozdanie/sprawozdanie.tex b/sprawozdanie/sprawozdanie.tex
index 59143bf..0575e23 100644
--- a/sprawozdanie/sprawozdanie.tex
+++ b/sprawozdanie/sprawozdanie.tex
@@ -28,6 +28,7 @@
 \usepackage{multirow}
 \usepackage{etoolbox}
 \usepackage{color}
+\usepackage{pgfkeys}
 
 \pgfplotsset{compat=1.15}
 \usepgfplotslibrary{groupplots}
@@ -40,10 +41,12 @@
 \newcommand{\todo}[1]{{\color{blue}\textbf{TODO:} #1}}
 
 \makeatletter
-\newcommand{\member}[2]{%
-    \ifcsdef{last}{\node[packet, right=of \last, text width=(#2*4mm)]}{\node[packet, text width=(#2*4mm)]} (#1) {\texttt{#1}};%
-    \node[below=of #1] {#2};
-    \def\last{#1}%
+\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]%
@@ -138,12 +141,10 @@ ten, który przyszedł pierwszy ponieważ są one od siebie niezależne.
 Protokół opiera się o wysyłanie datagramów UDP między wszystkimi klientami. Ze względu na specyfikę UDP (brak gwarancji
 dotarcia pakietów, brak gwarancji kolejności, brak gwarancji poprawności) przyjmuje się następujące założenia:
 \begin{itemize}
-    \item nie wszystkie pakiety są ważne
+    \item nie wszystkie pakiety są ważne, niektóre można pominąć
     \item wszystkie pakiety aby zostać przetworzone muszą dojść w całości poprawnie
     \item pakiety są numerowane
-    \item przez ważne pakiety rozumiemy te, które zmieniaja stan mapy
     \item pakiety mogą wymagać konkretnego poziomu stanu gry
-    \item pakiety zawierają timestamp aby w razie kolizji ustalić pierwszeństwo
 \end{itemize}
 
 Ze względu na konieczność szybkiego przesyłania informacji pomiędzy klientami, zaprojektowany protokół jest protokołem
@@ -158,10 +159,9 @@ binarnym, o konstrukcji pakietu widocznej poniżej.
         \member{ClientId}{2}
         \member{State}{4}
         \member{PacketId}{4}
-        \node[packet, dotted, right=of PacketId, text width=6cm] (Data) {Packet Data ...};
     \end{packet}
 
-    \caption{Budowa pakietu} 
+    \caption{Preambuła pakietu} 
 \end{figure}
 
 \begin{table}[H]
@@ -177,12 +177,43 @@ binarnym, o konstrukcji pakietu widocznej poniżej.
     \end{tabular}
 \end{table}
 
-Dla ułatwienia implementacji przyjmuje się, że dla pakietów, których najstarszy bit typu (\texttt{Type \& 0xC0}) jest
+Dla ułatwienia implementacji przyjmuje się, że dla pakietów, których najstarszy bit typu (\texttt{Type \& 0x80}) jest
 ustawiony na 1 nie zachodzi potrzeba retransmisji - czyli są to pakiety mało istotne bądź szybko przedawniające się.
 Przykładem takiego pakietu może być aktualizacja pozycji gracza - nie ma potrzeby retransmisji ponieważ prawdopodobnie i
 tak w drodze jest następny pakiet z nowszą pozycją.
 
-Aby upewnić się, że transmisja ważnego pakietu się powiodła, każdy klient musi zwrócić  
+W celu zapewnienia poprawności transmisji, każdy pakiet poprzedzany jest 32-bitową sumą kontrolną \texttt{CRC32},
+pozwalającą upewnić się, że dane zostały odebrane poprawnie. Suma kontrolna liczona jest ze wszystkich składowych
+pakietu poczynając od \texttt{Type} włącznie.
+
+W wypadku niezgodności przesłanej sumy kontrolnej z sumą wyliczoną po stronie odbierającego, odbierający wysyła pakiet
+\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
+wysłany ponownie. 
+
+W przypadku wielokrotnego otrzymania pakietu o tym samym \texttt{PacketId} (np. w wypadku automatycznej retramsnisji),
+każdorazowo należy potwierdzić jego otrzymanie odpowiedzią \texttt{ACK} jednak akcja związana z tym pakietem powinna
+zostać wykonana tylko raz. 
+
+Pakiety \texttt{ACK} oraz \texttt{RET} w polu \texttt{PacketId} zawierają id pakietu, którego dotyczą. Dodatkowo ze 
+wzgledu na to, że \texttt{ACK} nie jest bezpośrednio związany z rozgrywką, wymagany stan (\texttt{Sate}) zawsze wynosi 
+0.
+
+\begin{figure}[H]
+    \center
+    \begin{packet}
+        \member{CRC32}{4}
+        \member[Type]{0x80}{1}
+        \member[Size]{17}{2}
+        \member{ClientId}{2}
+        \member[State]{0}{4}
+        \member{PacketId}{4}
+    \end{packet}
+
+    \caption{Pakiet \texttt{ACK}} 
+\end{figure}
 
 \section{Rozwiązania}
 O nie w tym wypadku też ciężko