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

Fix things suggested by chktex

Browse Source
This commit is contained in:
Kristóf Tóth
2018-12-01 09:54:31 +01:00
parent d1751b0e7c
commit fb08ec81cb
3 changed files with 17 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
content/architecture.tex
View File

@ -17,8 +17,8 @@ The most important feature of the framework is it's messaging system.
Basically what we need is a system where processes running inside a Docker container
would be allowed to communicate with eachother.
This is easy 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 be
potentially on the other side of the planet -- would also need to partake in said communication.
The hard part is that frontend components running inside a web browser --- which could be
potentially on the other side of the planet --- 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.
The solution the framework uses is a proxy server, which connects to frontend components
@ -74,7 +74,7 @@ RabbitMQ%
ZMQ does not require a daemon (message broker process) and as such
has a much lower memory footprint while still providing various messaging
patterns and bindings for almost any widely used programming language.
An other -- yet untilized -- capability of this solution is that since ZMQ is capable
An other --- yet untilized --- capability of this solution is that since ZMQ is capable
of using simple TCP sockets, we could even communicate with processes running on remote
hosts using the framework.
@ -83,13 +83,13 @@ ZMQ which were also considered during the desing process of the framework at som
A few examples of top contenders and reasons for not using them in the end:
\begin{itemize}
\item The handling of raw TCP sockets would involve lot's of boilerplate logic that
already have quality implementations in messaging libraries: i.e. making sure that
already have quality implementations in messaging libraries: i.e.\ making sure that
all bytes are sent or received both require checking the return values of the
libc \texttt{send()} and \texttt{recv()} system calls, 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.
\item Using something like gRPC%
\footnote{\href{https://grpc.io}{https://grpc.io}} or plain HTTP (both of which
\item Using something like gRPC\footnote{\href{https://grpc.io}{https://grpc.io}}
or plain HTTP (both of which
are considered to be higher level than ZMQ sockets) would require
all processes partaking in the communication to be HTTP servers themselves,
which would make the framework