From c792f9fa86937210c3fdff87256fb1bc378cadf2 Mon Sep 17 00:00:00 2001 From: Kacper Donat Date: Sun, 15 Apr 2018 11:35:43 +0200 Subject: [PATCH] Sprawozdanie: rzeczy --- sprawozdanie/sprawozdanie.tex | 109 ++++++++++++++++++++++++---------- 1 file changed, 78 insertions(+), 31 deletions(-) diff --git a/sprawozdanie/sprawozdanie.tex b/sprawozdanie/sprawozdanie.tex index 0575e23..819cee8 100644 --- a/sprawozdanie/sprawozdanie.tex +++ b/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