1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
\documentclass[a4paper,9pt]{article}
\author{Camil Staps\\\small{s4498062}}
\title{Networking\\\large{Assignment 3}}
\usepackage{polyglossia}
\setmainlanguage{english}
\usepackage{geometry}
\usepackage[hidelinks]{hyperref}
\usepackage{caption}
\usepackage{enumitem}
\setenumerate{label=\alph*)}
\usepackage{minted}
\setminted{fontsize=\scriptsize}
\usepackage{subcaption}
\usepackage{tikz}
\usetikzlibrary{arrows,automata,shapes}
% underline to right side; see http://tex.stackexchange.com/a/137505/23992
\usepackage[normalem]{ulem}
\begin{document}
\maketitle
\section{SMTP Client}
\begin{enumerate}
\item \inputminted{python}{assignment3/smtpclient.py}
\item Encode it using any of the authentication mechanisms defined in RFC4954, that are supported by the server (as the client knows from the response to its \texttt{ehlo}).
\item Only the handshake and the \texttt{STARTTLS} request and its response. From then, all communication will be encrypted.
\item Most mail servers don't allow any authentication mechanism without first upgrading to an encrypted session. However, telnet cannot handle this encrypted connection.
\end{enumerate}
\section{Circular DHT}
\begin{enumerate}
\item $1\to3\to8\to11\to13$, so \textbf{4}; $13\to1$, so \textbf{1}; $3\to8\to11$, so \textbf{2}.
\item I'm assuming that peer 15 only knows about peer 1's existence. So, 1 is asked for the predecessor and successor of 15. This message is forwarded to peer 13, which realises that it will be 15's predecessor, and that its current successor (1) will be 15's successor. This information is sent to peer 15. This peer then sets its successor to 1, and its predecessor to 13. Furthermore, it notifies peer 13 to update its immediate successor to 15.
\item Peer 13 periodically checks if its successors on the first two levels (1 and 3) are still alive. When it cannot reach 1 any more, it will ask its second successor, 3, for its immediate successor (8). 13 then updates its successors to 3 and 8.
Similarly, peer 11 periodically checks if its successors (13 and 1) are still alive. When it cannot reach 1 any more, it will ask 13 for its immediate successor (3), and set its second successor to that.
If at that point 13 did not update its successor yet, and returns 1, then peer 11 can ask again after some time. Alternatively, 11 could send to 13 `I know that peer 1 died; if you haven't do so yet update your successors, and then send me your immediate successor.'
\item It takes $\mathcal O(n)$ to map a key to a node, where $n$ is the number of peers. An advantage is that it is easy to implement.
\end{enumerate}
\section{Design a protocol}
See \autoref{fig:3-fsm}.
\def\trans#1#2{\footnotesize{\texttt{\uline{#1\hfill\mbox{}}\\[2pt]#2}}}
\tikzstyle{trans}=[every trans]
\begin{figure}[h]
\def\nl{\\[-3pt]}
\centering
\begin{subfigure}{\textwidth}
\centering
\begin{tikzpicture}[node distance=35mm,->,>=stealth',every trans/.style={text width=4cm},every state/.style={ellipse}]
\node[initial,state] (a1) {Wait/Send};
\node[state,right of=a1] (a2) {Wait/Receive};
\path (a1) edge[bend left] node[trans,above] {\trans{rdt\_send(data)}{packet=make\_pkt(data)\nl udt\_send(packet)}} (a2)
(a2) edge[loop right,looseness=4.5] node[trans,right] {\trans{rdt\_send(data)}{rdt\_unable\_to\_send(data)}} (a2)
edge[bend left] node[trans,below] {\trans{rdt\_rcv(packet)}{extract(packet,data)\nl deliver\_data(data)}} (a1);
\end{tikzpicture}
\caption{Entity A}
\end{subfigure}
\begin{subfigure}{\textwidth}
\centering
\begin{tikzpicture}[node distance=35mm,->,>=stealth',every trans/.style={text width=4cm},every state/.style={ellipse}]
\node[state] (b1) {Wait/Receive};
\node[state,right of=b1] (b2) {Wait/Send};
\draw[<-] (b1) -- ++(-7mm,7mm) node[above left] {start};
\path (b2) edge[bend left] node[trans,below] {\trans{rdt\_send(data)}{packet=make\_pkt(data)\nl udt\_send(packet)}} (b1)
(b1) edge[loop left,looseness=4.5] node[trans,left] {\trans{rdt\_send(data)}{rdt\_unable\_to\_send(data)}} (b1)
edge[bend left] node[trans,above] {\trans{rdt\_rcv(packet)}{extract(packet,data)\nl deliver\_data(data)}} (b2);
\end{tikzpicture}
\caption{Entity B}
\end{subfigure}
\caption{Finite State Machines for our protocol}
\label{fig:3-fsm}
\end{figure}
\section{Analyse protocols}
\begin{description}
\item[GBN] As long as we cannot send two packets with the same sequence number at the same time, we're fine. A GBN receiver discards all packets but the packet it expects. Therefore, the largest allowable sender window is $k$.
\item[SR] It should not be the case that the receiver \emph{expects} a packet with sequence number $N$ \emph{and} finds another packet with sequence number $N$ \emph{acceptable}. Therefore, the largest allowable sender window (which equals the largest allowable receiver window) is $k$ for this protocol as well.
\end{description}
\end{document}
|
