mrtoth/thesis
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix some of the footnotes

Browse Source
This commit is contained in:
Kristóf Tóth
2018-12-03 16:47:09 +01:00
parent 766198cfd1
commit 40aa0d9f2f
4 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
content/architecture.tex
View File

@ -20,7 +20,7 @@ This task is very easy to solve, with lots of possible solutions
(named pipes, sockets or shared memory to name a few).
The hard part is that frontend components running inside a web browser --- which could
potentially be located on the other side of the planet%
\footnote{Potentially introducing all sorts of issues regarding latency} --- would
\footnote{Potentially introducing all sorts of issues regarding latency.} --- would
also need to partake in said communication.
So what we need to create is something of a hybrid between an IPC system and something
that can communicate with JavaScript running in a browser connected to it.
@ -54,7 +54,7 @@ some of the design decisions behind this:
The old way of creating dynamic webpages was AJAX%
\footnote{AJAX stands for Asynchronous JavaScript And XML, despite usually not having
anything to do with XML in practice}
anything to do with XML in practice.}
polling, which is basically sending
HTTP requests to a server at regular intervals from JavaScript to update the contents
of your website (and as such requiring to go over the whole TCP handshake and the
@ -68,7 +68,7 @@ This allows for communication with lower overhead and latency facilitating effic
real-time applications, which were not always possible to create before due to
the overheads%
\footnote{In some applications this overhead could be bigger than the actual data sent,
such as singaling} introduced by AJAX polling.
such as singaling.} introduced by AJAX polling.
The Tutorial Framework uses WebSockets to connect to it's web frontend.
The TFW proxy server is capable to connecting to an arbirary number of WebSockets,
@ -101,7 +101,7 @@ A few examples of top contenders and reasons for not using them in the end:
all bytes are sent or received both require constantly checking the return values of the
libc \code{send()} and \code{recv()} system calls%
\footnote{Developers forget this very often, resulting in almost untraceable bugs
that seem to occour randomly},
that seem to occour randomly.},
while ZMQ takes care of this
extra logic involved and even provides higher level messaging patterns such as
subscribe-publish, which would need to be implemented on top of raw sockets again.
@ -114,9 +114,9 @@ that seem to occour randomly},
force you to write synchronous or asynchronous code, whereas common HTTP servers
are either async%
\footnote{Async servers use the \code{select} or \code{epoll} system calls among others
to avoid blocking on IO} or pre-fork%
to avoid blocking on IO.} or pre-fork%
\footnote{Pre-fork servers spawn multiple processes and threads to handle requests
simultaneously} in nature, which extorts certain design choices on code
simultaneously.} in nature, which extorts certain design choices on code
built on them.
\end{itemize}
@ -172,7 +172,7 @@ All valid messages \emph{must} include a \code{key} field as this is used by the
framework for addressing: event handlers and frontend components subscribe to one
or more of these \code{key}s and only receive%
\footnote{In reality they do receive them, just like how network interfaces receive all
ethernet frames, they just choose ignore the ones not concerning them}
ethernet frames, they just choose ignore the ones not concerning them.}
messages with \code{key}s that they have
subscribed to.
It is possible to send a message with an empty key, however these messages will not