summaryrefslogtreecommitdiffstats
path: root/thesis
diff options
context:
space:
mode:
authorDavid Runge <dave@sleepmap.de>2017-07-08 16:06:55 +0200
committerDavid Runge <dave@sleepmap.de>2017-07-08 16:06:55 +0200
commit8ebed5430eab91a62c926271d0053711f5115051 (patch)
tree9fd35a129da171c6722ba0b8b7785f8a73dd7da4 /thesis
parent9b8b7229b412ea126d7de9c72b164af373ee7954 (diff)
downloadmaster-thesis-8ebed5430eab91a62c926271d0053711f5115051.tar.gz
master-thesis-8ebed5430eab91a62c926271d0053711f5115051.tar.bz2
master-thesis-8ebed5430eab91a62c926271d0053711f5115051.tar.xz
master-thesis-8ebed5430eab91a62c926271d0053711f5115051.zip
thesis/thesis.tex: Moving automated tests to discussion section.
Diffstat (limited to 'thesis')
-rw-r--r--thesis/thesis.tex112
1 files changed, 57 insertions, 55 deletions
diff --git a/thesis/thesis.tex b/thesis/thesis.tex
index 7d752c3..cd7d1c8 100644
--- a/thesis/thesis.tex
+++ b/thesis/thesis.tex
@@ -1655,6 +1655,63 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
relevant messages, as explained in
\nameref{subsubsec:message_interface}.\\
+ \cleardoublepage
+ \section{Discussion}
+ \label{sec:discussion}
+ The \gls{osc} based networking extension created for the \gls{ssr} is a
+ valuable usability improvement. Its implemented features are discussed
+ further in the following section, followed by an outlook on related
+ future work.\\
+ Due to the versatility of how the \gls{ssr} can be used in a networking
+ context, its likely, that some of its possibilities are not even accounted
+ for.
+
+ \subsection{Implemented Features}
+ \label{subsec:implemented_features}
+ The \gls{osc} interface described in~\ref{subsec:osc-interface} can be
+ seen as a full replacement (with one minor exception, detailed
+ in~\ref{subsubsec:scene_transfer}) for the \gls{ip} interface, already in
+ place. Its additional features are what set it trully apart though, when
+ not only regarding non-reliance on external software to enable \gls{osc}
+ capabilities.\\
+
+ The implementation follows the internal \gls{pubsub} interface, as
+ described in~\ref{subsec:publisher_subscriber_interface} and extends it,
+ where appropriate. Additionally an open client-server architecture has
+ been created, according to a message level system, further elaborated
+ upon in \gls{subsubsec:message_levels}. An attempt at giving extensive
+ examples on the various setup possibilities, that are now possible, is
+ made in \gls{subsubsec:setups}, some of which are still dependant on
+ various missing features (see~\ref{subsec:future_work}).\\
+ The \gls{osc} messaging system is adhering to the aforementioned
+ client-server architecture by distinguishing between client-only,
+ server-only and messages available to clients and servers alike
+ (see~\ref{subsubsec:message_interface}). Examples for different workflows
+ are given in~\ref{subsubsec:workflow_examples} to illustrate simple
+ use-cases.\\
+ This puts the \gls{osc} interface in the unique position of providing a
+ native messaging interface and a flexible architecture. It can be used
+ from single local instances up to large scale networked setups (with the
+ limitations discussed in~\ref{subsubsec:alien_loudspeaker}
+ and~\ref{subsubsec:assigning_in_and_outputs_on_the_fly}).\\
+ While with the \gls{ip} interface, multiple instances are only
+ controllable by using an \gls{osc} capable application or one, that is
+ able to send \gls{xml}-formatted strings over \gls{tcp}/\gls{ip}, the
+ \gls{osc} interface can deal with \textit{n} clients natively, while only
+ one instance has to be controlled using \gls{osc}. The behavior implies,
+ that setups are possible, in which a large collection of different types
+ of renderers can share the same scene, which is particularly useful for
+ e.g.\ auditioning different rendering algorithms over the same system, or
+ rather in the same room.\\
+ Message sending takes place over \gls{udp}, instead of \gls{tcp}, which
+ lowers the complexity of the network topology (\gls{udp} does not perform
+ handshakes for every packet sent, unlike \gls{tcp}) and thus the size of
+ each message sent.\\
+ The \gls{osc} interface therefore implements messaging, using lower
+ bandwidth, at a greater feature set. In~\ref{subsec:automated_tests} a
+ test environment is introduced, that further elaborates on the overall
+ functionality and feasibility of the message interface.
+
\subsection{Automated tests}
\label{subsec:automated_tests}
The \gls{ssr} was developed without the help of a test framework, which
@@ -1795,61 +1852,6 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
\gls{osc} message received and sent above the aforementioned verbosity
level.
- \cleardoublepage
- \section{Discussion}
- \label{sec:discussion}
- The \gls{osc} based networking extension created for the \gls{ssr} is a
- valuable usability improvement. Its implemented features are discussed
- further in the following section, followed by an outlook on related
- future work.\\
- Due to the versatility of how the \gls{ssr} can be used in a networking
- context, its likely, that some of its possibilities are not even accounted
- for.
-
- \subsection{Implemented Features}
- \label{subsec:implemented_features}
- The \gls{osc} interface described in~\ref{subsec:osc-interface} can be
- seen as a full replacement (with one minor exception, detailed
- in~\ref{subsubsec:scene_transfer}) for the \gls{ip} interface, already in
- place. Its additional features are what set it trully apart though, when
- not only regarding non-reliance on external software to enable \gls{osc}
- capabilities.\\
-
- The implementation follows the internal \gls{pubsub} interface, as
- described in~\ref{subsec:publisher_subscriber_interface} and extends it,
- where appropriate. Additionally an open client-server architecture has
- been created, according to a message level system, further elaborated
- upon in \gls{subsubsec:message_levels}. An attempt at giving extensive
- examples on the various setup possibilities, that are now possible, is
- made in \gls{subsubsec:setups}, some of which are still dependant on
- various missing features (see~\ref{subsec:future_work}).\\
- The \gls{osc} messaging system is adhering to the aforementioned
- client-server architecture by distinguishing between client-only,
- server-only and messages available to clients and servers alike
- (see~\ref{subsubsec:message_interface}). Examples for different workflows
- are given in~\ref{subsubsec:workflow_examples} to illustrate simple
- use-cases.\\
- This puts the \gls{osc} interface in the unique position of providing a
- native messaging interface and a flexible architecture. It can be used
- from single local instances up to large scale networked setups (with the
- limitations discussed in~\ref{subsubsec:alien_loudspeaker}
- and~\ref{subsubsec:assigning_in_and_outputs_on_the_fly}).\\
- While with the \gls{ip} interface, multiple instances are only
- controllable by using an \gls{osc} capable application or one, that is
- able to send \gls{xml}-formatted strings over \gls{tcp}/\gls{ip}, the
- \gls{osc} interface can deal with \textit{n} clients natively, while only
- one instance has to be controlled using \gls{osc}. The behavior implies,
- that setups are possible, in which a large collection of different types
- of renderers can share the same scene, which is particularly useful for
- e.g.\ auditioning different rendering algorithms over the same system, or
- rather in the same room.\\
- Message sending takes place over \gls{udp}, instead of \gls{tcp}, which
- lowers the complexity of the network topology (\gls{udp} does not perform
- handshakes for every packet sent, unlike \gls{tcp}) and thus the size of
- each message sent.\\
- The \gls{osc} interface therefore implements messaging using lower
- bandwidth at a greater feature set.
-
\subsection{Future Work}
\label{subsec:future_work}
Several features, interesting for different use-cases, could not be