diff options
Diffstat (limited to 'taler/implementation.tex')
| -rw-r--r-- | taler/implementation.tex | 37 |
1 files changed, 15 insertions, 22 deletions
diff --git a/taler/implementation.tex b/taler/implementation.tex index d6647f5..bbc1eb8 100644 --- a/taler/implementation.tex +++ b/taler/implementation.tex @@ -2061,22 +2061,16 @@ already terminated before it reaches the exchange service, and exchanges can be operated securely even without TLS. The comparison between no additional delay and a \SI{100}{\milli\second} delay -is shown in Table~\ref{table:latency}. As TCP Fast Open was enabled on both \texttt{gv} -and \texttt{firefly} - -In the incremental request to -\texttt{/keys} (which only returns keys added after the requested date), the -artificial latency reveals that the request is completed with one round trip. -The request is already sent in the first TCP packet from the client to the -exchange, as TCP Fast Open \cite{rfc7413} is enabled on both \texttt{gv} and -\texttt{firefly} and supported by GNU Taler. Without TCP Fast Open, we would -observe an extra round trip for the SYN and SYN/ACK packages without any -payload. - -All other requests require an extra roundtrip, adding up to an additional delay -of about \SI{400}{\milli\second}. This can be explained by the larger size of -their response body. Due to TCP congestion control, the exchage does not send -the complete response at once, but waits for an ACK from the client. +is shown in Table~\ref{table:latency}. TCP Fast Open was enabled on both +\texttt{gv} and \texttt{firefly}. Since for all operations except +\texttt{/refresh/reveal}, both request and response fit into one TCP segment, +the operations complete within one round-trip time. This explains the +additional delay of $\approx \SI{200}{\milli\second}$ when the artificial +delay is introduced. Without TCP Fast Open, we would observe an extra round +trip for the SYN and SYN/ACK packages without any payload. The +\texttt{/refresh/reveal} operation takes an extra roundtrip due to the +relatively large size of the response, which contains the signatures for +multiple coins. Figure~\ref{fig:latencies} shows the latency for the exchange's HTTP endpoints in relation to different network delays. As expected, the additional delay @@ -2097,12 +2091,11 @@ be linear, due to timeouts raised by clients. {\specialcell[c]{Request size\\(\si{\kilo\byte})}} & {\specialcell{Response size\\(\si{\kilo\byte})}} \\ \midrule - %\texttt{/keys} (incremental) & 0.52 & 200.55 \\ - \texttt{/keys} & 1.01 & 201.042 & 0.012 & 3.72 \\ - \texttt{/deposit} & 28.94 & 434.212 & 3.97 & 0.34 \\ - \texttt{/reserve/withdraw} & 29.38 & 432.491 & 2.95 & 0.72 \\ - \texttt{/refresh/melt} & 37.0143 & 419.80 & 3.55 & 0.35 \\ - \texttt{/refresh/reveal} & 82.87 & 483.33 & 3.84 & 2.11 \\ + \texttt{/keys} & 1.14 & 201.25 & 0.14 & 1.67 \\ + \texttt{/reserve/withdraw} & 22.68 & 222.46 & 0.71 & 0.73 \\ + \texttt{/deposit} & 22.36 & 223.22 & 1.40 & 0.34 \\ + \texttt{/refresh/melt} & 20.71 & 223.9 & 1.06 & 0.35 \\ + \texttt{/refresh/reveal} & 63.64 & 466.30 & 1.67 & 2.11 \\ \bottomrule \end{tabular} \caption{Effects of \SI{100}{\milli\second} symmetric network delay on total latency.} |