report.tex

\documentclass[11pt]{article}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[english]{babel}

\usepackage{hyperref}
\usepackage{amsmath,amssymb}
\usepackage{graphicx}
\usepackage{array}
\usepackage{caption}
\usepackage{booktabs}
\usepackage{threeparttable}
\usepackage{amsmath}
\usepackage{array}
\usepackage{tabularx}
\usepackage{lmodern} % police Latin Modern
\usepackage{hyperref}
\usepackage{fancyhdr}
\usepackage[top=3cm, bottom=2cm, left=2cm, right=2cm]{geometry}
\pagestyle{fancy}
\lhead{Delaunoy Arnaud s153059}
\hypersetup{                    % parametrage des hyperliens
    colorlinks=true,                % colorise les liens
    breaklinks=true,                % permet les retours à la ligne pour les liens trop longs
    urlcolor= black,                 % couleur des hyperliens
    linkcolor= black,                % couleur des liens internes aux documents (index, figures, tableaux, equations,...)
    citecolor= green                % couleur des liens vers les references bibliographiques
    }
\title{Computer networking: project 2}
\author{ Adrien Minne s154340 \\ Delaunoy Arnaud s153059}
\date{}
\lhead{ Adrien Minne s154340 \\ Delaunoy Arnaud s153059}
%\renewcommand\thesection{}
%\renewcommand\thesubsection{}
%\renewcommand\thesubsubsection{}

\begin{document}
\begin{titlepage}
\maketitle
\setcounter{page}{0}
\thispagestyle{empty}
\end{titlepage}

\section{Software architecture}

\subsection{connexion handling}

\subsubsection{WebServer}
This is the main class. Its job is to manage the sockets; it accepts clients and assign a new Worker for handling the client's request. It thus handle the threadpool mechanism.\\
In addition to that it also keeps manage the cookies of all the clients providing a method for creating new cookies and getting cookie from their id. However, this class only handle the storing of the cookies and not the mechanisms that come with it.

\subsubsection{Worker}
This is a thread class that handle a client's request given its socket. To do so it calls the RequestHandler and close the socket when the Request is handled.

\subsection{Request handling}

\subsubsection{RequestHandler}
This class has a private constructor and is not meant to be instantiated. It provides a static method for handling request based on the client sockets.

\subsubsection{HTTPRequest}
This class represent a request of the HTTP protocol. The main job of this class if performed by its constructor as it takes a socket as argument and construct parsing what is given through this socket. It also performs some checks about the consistency of what's given though the socket. The pieces of information about this request are then easily accessible by getting the values of the variables of the HTTPRequest object.

\subsubsection{HTTPReply}
This class represent a reply of the HTTP protocol. It works as the opposite of the HTTPRequest. The constructor takes as arguments The different pieces of information of the reply and have a method to send it through a socket with the HTTP protocol. The HTML page contains references to png files representing the colored circles, we thus had to make sure that our server handled correctly requests for image file in addition to the request for the HTML page itself. It also provide method to send the reply to the client, after encoding the reply body in GZip, using chunk encoding.

\subsubsection{HTTPRedirectionReply}
This class inherit from HTTPReply and provides a constructor that create a reply for redirection taking only the location as argument; the other components being always the same for any redirection.

\subsubsection{HTTPRErrorReply}
This class inherit from HTTPReply and provides a constructor that create a reply for an HTTP error. It create a simple HTML page displaying the error message.

\subsubsection{MethodExecutor}
This is an abstract class. It has an abstract method called process that produce the appropriate HTTPReply object given a HTTPRequest object. This abstract method is then implemented by either the \texttt{GetMethodExecutor}, \texttt{PostMethodExecutor} or \texttt{HeadMethodExecutor} Which implement the logic of a get, post, head request. It also provides a method to manage cookies. It modifies the headers of a reply given the headers of the request. It also modifies the cookie associated to this Executor and the cookie list according to the situation.

\subsection{client side}
\subsubsection{HTMLPage and HTMLErrorPage}
These two classes generate HTML code. HTMLPage generate the HTML code of the main page of the game, and HTMLErrorPage generate a simple page where we display the HTTP error code. The HTMLPage is generated by reading a HTML file and inserting into it a list of combinations created in the Java code. 

\subsubsection{WebsiteFiles}
We decided to create separates files for the CSS and JavaScript, which allows the client to cache them instead of loading them every time. The WebsiteFiles enumeration contains the path of those files, as well as a method to read these file and put them into a String that will be used as the body of the request.

\subsection{Other classes}

\subsubsection{Colors}
Enumeration representing a Color providing some basic method associated to it.

\subsubsection{Combination}
This class represent a Combination (Combination + result). It also provides a method parse a string containing the representation of a combination in order to set the combination of the object. It provides a method to set a random combination and a method to evaluate the combination setting the results based on a comparison combination given in argument.


\subsubsection{Cookie}
The cookies are represented in a Cookie class in Java. They are stored on the server in a static ArrayList in the Webserver class. Inside the Cookie class, we memorize all the tried combinations of the user, the correct combination, as well as the creation date of the cookies to be able to check whether it's expired or not. The class also contains a method to generate an HTMLPage from the combination tried by the user. \\

When handling a request, we check in the MethodExecutor class if the user did send a cookie. We then check if the cookies has expired and reset it if it is, then we use this cookie to generate the correct HTTP Reply body. If the client didn't send any cookie ID, we create a new cookie for it and send it with the reply. As some clients may discard the cookie expiration date, we don't send any. It means that a client will always use the same cookie ID for every game it plays, only the content of the cookie in the server will change and it's the server that will check if the cookie expired. It makes it simpler to manage cookie, but can induce minors problems discussed int the sections "limits" and "possible imrovements". 

\subsubsection{FileType}
Enumeration that contain the types that can be sent through a request or reply. It contain a string indicating the header value associated to it and a boolean indicating if this type is represented by a string.

\subsubsection{HTTP}
This class holds some general pieces of information about the HTTP protocol such as the version and a method to get the server time.

\subsubsection{HTTPOption}
This is an enumeration containing all the possible headers. It contain a string indicating how this header is represented in the HTTP protocol and some basic methods associated to it.

\subsubsection{ReturnCode}
This is an enumeration holding the return codes that we have to use in this project. To each return code is associated its number and the corresponding status.

\section{Multi-thread coordination}
Having different cookie id for each user allow to totally separate The variables the threads are working on and thus makes coordination mechanisms unneeded.

\section{Limits}
\begin{itemize}
\item The cookies aren't send with an expiration date, a client will always keep the same cookie. The only problem with this is that if a client clear all it's cookies, the cookie it previously used will stay in the memory of the server
\end{itemize}


\section{Possible improvements}
\begin{itemize}
\item 
To prevent the accumulation of cookies on the server, we could've for example created another thread that would periodically search for expired cookies and delete them. The problem is that this thread could induce a lot of synchronization problems (e.g. it tries to clear a expired cookie, but at the same time the client using this cookies tries to connect to the server). These problems aren't trivial at all to solve, so we chose to ignore them. But as  clearing cookies isn't something that people often does, we judged that trying to solve all the new synchronizations problems that would arise wasn't worth it. \\ 
\end{itemize}

\end{document}