1.1 --- a/thesis/tex/5-Improvements.tex	Sat Jan 24 17:04:09 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Sun Jan 25 20:31:54 2009 +0100
     1.3 @@ -362,34 +362,6 @@
     1.4  
     1.5  
     1.6  
     1.7 -\subsubsection*{Inter-module communication}
     1.8 -
     1.9 -Communication between modules is required to exchange data and status information. This is also called ``Inter-process communication'' (short: \NAME{IPC}) because the modules are independent programs in this case and processes are programs in execution.
    1.10 -
    1.11 -The connections between \name{queue-in} and \name{scanning}, as well as between \name{scanning} and \name{queue-out} is provided by the queues, only sending signals to trigger runs may be useful. Communication between receiving and transport modules and the outside world are done using the specific protocol they do handle.
    1.12 -
    1.13 -Left is only communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Data is exchanged using \unix\ pipes and a simple protocol. Figure \ref{fig:ipc-protocol} shows a state diagram for the protocol. Solid lines indicate client actions, dashed lines indicate server responses.
    1.14 -
    1.15 -\begin{figure}
    1.16 -	\begin{center}
    1.17 -		\includegraphics[scale=0.75]{img/ipc-protocol.eps}
    1.18 -	\end{center}
    1.19 -	\caption{State diagram of the \NAME{IPC} protocol}
    1.20 -	\label{fig:ipc-protocol}
    1.21 -\end{figure}
    1.22 -
    1.23 -\paragraph{Timing}
    1.24 -One dialog consists of exactly three phases: connection attempt, envelope and header transfer, and transfer of the message body. The order is always the same. The three phases are all initiated by the client process; after each phase the server process sends a success or error reply. Timeouts for each phase need to be implemented.
    1.25 -
    1.26 -\paragraph{Semantics}
    1.27 -The connection attempt is simply opening the connection. This starts the dialog. A positive reply by the server leads to the transfer of envelope and message header. If the server again sends a positive reply, the message data is transferred too. A last server reply ends the dialog.
    1.28 -
    1.29 -The client indicates the end of each data transfer with a special terminator sequence. The appearance of this terminator sequence tells the server process that the data transfer is complete and makes the server send a reply. The server process takes responsibility of the data in sending a success reply. A failure reply immediately stops the dialog and resets both client and server to the state before the connection attempt.
    1.30 -
    1.31 -\paragraph{Syntax}
    1.32 -Data transfer is done by sending plain text data. \name{Line Feed}---the native line separator on \unix---is used as line separator. The terminator sequence used to indicate the end of the data transfer is the \NAME{ASCII} \name{null} character (`\texttt{\textbackslash0}'). Replies are one-digit numbers with `\texttt{0}' meaning success and any other number (`\texttt{1}'--`\texttt{9}') indicate failure.
    1.33 -
    1.34 -
    1.35  
    1.36  \subsubsection*{The queue}
    1.37  
    1.38 @@ -420,14 +392,45 @@
    1.39  %The \name{incoming} queue stores envelope and the message header of messages received via one of the incoming channels. The data is in unprocessed form. The \name{outgoing} queue contains processed data. The header and envelope information is complete and in valid form. The \name{pool} is the storage of the message bodies of queued messages. This data is not changed within the \MTA, it is written on reception and read on dispatch.
    1.40  
    1.41  
    1.42 -
    1.43 -
    1.44  A sample spool file. With comments in parenthesis.
    1.45  \codeinput{input/sample-spool-file.txt}
    1.46  
    1.47  
    1.48  
    1.49  
    1.50 +
    1.51 +
    1.52 +\subsubsection*{Inter-module communication}
    1.53 +
    1.54 +Communication between modules is required to exchange data and status information. This is also called ``Inter-process communication'' (short: \NAME{IPC}) because the modules are independent programs in this case and processes are programs in execution.
    1.55 +
    1.56 +The connections between \name{queue-in} and \name{scanning}, as well as between \name{scanning} and \name{queue-out} is provided by the queues, only sending signals to trigger runs may be useful. Communication between receiving and transport modules and the outside world are done using the specific protocol they do handle.
    1.57 +
    1.58 +Left is only communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Data is exchanged using \unix\ pipes and a simple protocol. Figure \ref{fig:ipc-protocol} shows a state diagram for the protocol. Solid lines indicate client actions, dashed lines indicate server responses.
    1.59 +
    1.60 +\begin{figure}
    1.61 +	\begin{center}
    1.62 +		\includegraphics[scale=0.75]{img/ipc-protocol.eps}
    1.63 +	\end{center}
    1.64 +	\caption{State diagram of the \NAME{IPC} protocol}
    1.65 +	\label{fig:ipc-protocol}
    1.66 +\end{figure}
    1.67 +
    1.68 +\paragraph{Timing}
    1.69 +One dialog consists of exactly three phases: connection attempt, envelope and header transfer, and transfer of the message body. The order is always the same. The three phases are all initiated by the client process; after each phase the server process sends a success or error reply. Timeouts for each phase need to be implemented.
    1.70 +
    1.71 +\paragraph{Semantics}
    1.72 +The connection attempt is simply opening the connection. This starts the dialog. A positive reply by the server leads to the transfer of envelope and message header. If the server again sends a positive reply, the message data is transferred too. A last server reply ends the dialog.
    1.73 +
    1.74 +The client indicates the end of each data transfer with a special terminator sequence. The appearance of this terminator sequence tells the server process that the data transfer is complete and makes the server send a reply. The server process takes responsibility of the data in sending a success reply. A failure reply immediately stops the dialog and resets both client and server to the state before the connection attempt.
    1.75 +
    1.76 +\paragraph{Syntax}
    1.77 +Data transfer is done by sending plain text data. \name{Line Feed}---the native line separator on \unix---is used as line separator. The terminator sequence used to indicate the end of the data transfer is the \NAME{ASCII} \name{null} character (`\texttt{\textbackslash0}'). Replies are one-digit numbers with `\texttt{0}' meaning success and any other number (`\texttt{1}'--`\texttt{9}') indicate failure.
    1.78 +
    1.79 +
    1.80 +
    1.81 +
    1.82 +
    1.83  \subsubsection*{Rights and permission}
    1.84  
    1.85  The set of system users that is required for \qmail\ seems to be too complex. One system user, like \postfix\ uses, is more appropriate. \name{root} privilege and \name{setuid} permission needs to be avoided as feasible.