\chapter{Answers}\label{chap:answers}

\section*{Chapter~\ref{chap:introduction}}

\begin{enumerate}

\item NoTA is a framework for communication within and between devices. NoTA

  is also a specific implementation of this framework (the reference

  implementation). NoTA can be used to connect hardware and software

  in a standardized way;

\item A good working knowledge of the C programming language is very useful,

  as is some experience with UNIX/Linux-based systems;

\item No, not necessarily. You could start with chapter~\ref{chap:stubgen}

  (about the stub-generator) and later on read chapters~\ref{chap:h-in}

  and~\ref{chap:h-in-example} (about the {\tt h\_in});

\item Left as an exercise to the reader.

\end{enumerate}

\section*{Chapter~\ref{chap:overview}}

\begin{enumerate}

\item NoTA nodes come in two flavors: {\em application nodes} and {\em

    service nodes}. Application nodes are the 'clients' in the system, that

  request services from {\em service nodes}. The application nodes initiates

  the initial contact with the service node; after that, communications may

  flow in either way;

\item Message passing (in NoTA) is asynchronous communication between nodes,

  where response can come at any time; function calls are synchronous, and

  return their results to the caller; the former are more general, but also

  harder to program;

\item Message passing is useful for sending control messages such as '{\tt

    send\_sms()}' or notifications '{\tt received\_sms()'}, while streaming is

  better for sending/receiving bulk data (such as sending a picture to another

  node);

\item The {\tt l\_in} (low-level interconnect) takes care of network-level

  issues and abstracts away the transport details, while the {\tt h\_in}

  (high-level interconnect) provides ways for the nodes to communicate;

\item You can use the resource manager to resolve (= find) service

  addresses. The stub-generator can generate a lot of the 'plumbing' code from

  the service definitions, saving you a lot of work;

\item No - there's nothing Linux/UNIX-specific in the NoTA-standards. The

  reference implementation has been ported to non-UNIX platforms (Symbian,

  Tron).

\end{enumerate}

\section*{Chapter~\ref{chap:h-in}}

\begin{enumerate}

\item NoTA functions have and 'H'-prefix. FIXME

\item {\tt Hsend()} 

\end{enumerate}

\section*{Chapter~\ref{chap:messages}}

\begin{enumerate}

\item The mapping from number to message has to be agreed upon by AN and SN --

  there is no inherent way to know what message corresponds to, say, signal-id

  \texttt{0x0100}. You can \texttt{\#define} the values in a shared header file

  for client and server, or you can let the stub-generator

  (chapter~\ref{chap:stubgen}) do that for you;

\item {\tt 0xa2, 0x01, 0x00, 0x60, 0x11, 0x05, 0x11, 0x07, 0x11, 0x17, 0x61};

\item {\tt ``XXXV''} and 35.

\item Even though many of the mainstream platform use little-endian encoding,

  there are big-endian platforms out there as well. Unless you are sure that

  your code will never need to run on anything \emph{but} little-endian

  machines, you should take this into account.

\end{enumerate}

\section*{Chapter~\ref{chap:h-in-example}}

\begin{enumerate}

\item We got the socket with the {\tt SOCK\_SEQPACKET} option, so NoTA

  guarantees that the whole message will available at the receiving

  side. However, blocking {\em could} occur with the first {\tt Hrecv}, if the

  message has not been received at all yet;

\item The example implementation is {\em not} asynchronous, so the response

  always directly follows the request. If they {\em were} asynchronous, indeed

  there could be problems to figure out which request and response belong

  together. A common solution to that is the use of {\em cookies}, i.e. in the

  request you pass some unique number, and the same number is returned with

  the response;

\item Left as an exercise for the reader...

\item 'ravine'.

\end{enumerate}

\section*{Chapter~\ref{chap:stubgen}}

\begin{enumerate}

    \item Advantage: with the stub-generator you can focus on your the service

  you would like to define, instead of implementation details. The service

  definitions allow easy communication with other parties. There are

  significant advantages in programmer productivity. Disadvantages: when there

  is some problem in the stub-generator-generated code, it may be hard to

  debug;

    \item No, the NoTA service definitions are not fully compatible; for

  example, some parts of WSDL are ignored, such as {\em Operations}, {\em Port

  Types}, {\em Bindings}, {\em Ports} and {\em Services}; the same is true for

  many of the attributes of {\tt definition} and {\tt element}-elements. 

  NoTA service definitions support a {\em subset} of WSDL 1.1.

\end{enumerate}

\section*{Chapter~\ref{chap:stubgen-example}}

\section*{Chapter~\ref{chap:rm}}

\begin{enumerate}

\item Resolving services; similar to what a Domain Name Server does for

  internet services;

\item An ontology is a sort-of namespace in which a number of related NoTA

  services live. A service description is a structured string uniquely

  describing one particular service in an ontology;

\item The resource manager has a fixed address: \texttt{NOTA\_RM\_ADDRESS = {

      0, 0, 0 };};  

\item Use the \texttt{ResolveService}-messages;

\item Use the \texttt{NewEvent}-messages.

\end{enumerate}

\section*{Chapter~\ref{chap:development}}

\begin{enumerate}

\item {\tt \_req} is AN$\to$SN-requests, {\tt \_cnf} is for

  SN$\to$AN-confirmations, {\tt \_ind} is for SN$\to$AN-indications

  (unsolicited messages) and finally, {\tt \_rsp} is for AN$\to$SN-responses

  to {\tt \_ind}-messages. Messages are sent by the node on the left side of

  the arrow, and must be handled (implemented) by the right side.

\end{enumerate}