diff options
Diffstat (limited to 'thesis')
| -rw-r--r-- | thesis/thesis.tex | 112 |
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 |