PG/ProjektPR
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Sprawozdanie: ACK i RET

Browse Source
This commit is contained in:
Kacper Donat 2018-04-14 12:05:33 +02:00
parent c746e560c0
commit bcd17576bb
1 changed files with 42 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
sprawozdanie/sprawozdanie.tex
View File

@ -28,6 +28,7 @@
\usepackage{multirow} \usepackage{multirow}
\usepackage{etoolbox} \usepackage{etoolbox}
\usepackage{color} \usepackage{color}
\usepackage{pgfkeys}
\pgfplotsset{compat=1.15} \pgfplotsset{compat=1.15}
\usepgfplotslibrary{groupplots} \usepgfplotslibrary{groupplots}
@ -40,10 +41,12 @@
\newcommand{\todo}[1]{{\color{blue}\textbf{TODO:} #1}} \newcommand{\todo}[1]{{\color{blue}\textbf{TODO:} #1}}
\makeatletter \makeatletter
\newcommand{\member}[2]{% \newrobustcmd{\member}[3][]{%
\ifcsdef{last}{\node[packet, right=of \last, text width=(#2*4mm)]}{\node[packet, text width=(#2*4mm)]} (#1) {\texttt{#1}};% \ifcsdef{last}{\node[packet, right=of \last, text width=(#3*7.5mm)]}{\node[packet, text width=(#3*7.5mm)]} (#2)
\node[below=of #1] {#2}; {\texttt{#2}};%
\def\last{#1}% \node[below=of #2] {#3};
\node[above=of #2.north, text depth=0pt] {\texttt{#1}};
\def\last{#2}%
}% }%
\newenvironment{packet}{% \newenvironment{packet}{%
\begin{tikzpicture}[packet/.style={draw, auto, align=center, minimum height=7mm}, node distance=0]% \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 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: dotarcia pakietów, brak gwarancji kolejności, brak gwarancji poprawności) przyjmuje się następujące założenia:
\begin{itemize} \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 wszystkie pakiety aby zostać przetworzone muszą dojść w całości poprawnie
\item pakiety są numerowane \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 mogą wymagać konkretnego poziomu stanu gry
\item pakiety zawierają timestamp aby w razie kolizji ustalić pierwszeństwo
\end{itemize} \end{itemize}
Ze względu na konieczność szybkiego przesyłania informacji pomiędzy klientami, zaprojektowany protokół jest protokołem 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{ClientId}{2}
\member{State}{4} \member{State}{4}
\member{PacketId}{4} \member{PacketId}{4}
\node[packet, dotted, right=of PacketId, text width=6cm] (Data) {Packet Data ...};
\end{packet} \end{packet}
\caption{Budowa pakietu} \caption{Preambuła pakietu}
\end{figure} \end{figure}
\begin{table}[H] \begin{table}[H]
@ -177,12 +177,43 @@ binarnym, o konstrukcji pakietu widocznej poniżej.
\end{tabular} \end{tabular}
\end{table} \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ę. 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 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ą. 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} \section{Rozwiązania}
O nie w tym wypadku też ciężko O nie w tym wypadku też ciężko