1.1 --- a/thesis/tex/5-Improvements.tex	Fri Jan 23 21:55:37 2009 +0100
     1.2 +++ b/thesis/tex/5-Improvements.tex	Fri Jan 23 21:56:45 2009 +0100
     1.3 @@ -351,8 +351,7 @@
     1.4  The \name{scanning} module is the central part of the system. It takes spooled messages from the \name{incoming} queue, works on them, and writes them to the \name{outgoing} queue afterwards (the message is then removed from the \name{incoming} queue, of course). The main job is the processing done on the message. Headers are fixed and missing ones are added if necessary, aliasing is done, and external processing of any kind is triggered. The \name{scanning} module can run in background and look for new mail in regular intvals or signals may be sent to it by \name{queue-in}. Alternatively it can be called by \name{cron}, for example, to do single runs.
     1.5  
     1.6  
     1.7 -The \name{queue-out} module takes messages from the \name{outgoing} queue, queries information about the online connection, and then selects matching routes, creates envelopes for each recipient and passes the messages to the correct transport module. Successfully transfered messages are removed from the \name{outgoing} queue. This module includes some tasks specific to \masqmail.
     1.8 -%fixme: rework route selection
     1.9 +The \name{queue-out} module takes messages from the \name{outgoing} queue, queries information about the online state which specifies the route to use, creates envelopes for each recipient, and passes the messages to the correct transport module. Successfully transfered messages are removed from the \name{outgoing} queue. This module includes some tasks specific to \masqmail.
    1.10  
    1.11  
    1.12  The \name{incoming} queue stores messages received via one of the incoming channels. The messages are in unprocessed form; only envelope data is prepended.
    1.13 @@ -364,44 +363,36 @@
    1.14  %fixme: get invoked by inetd, or better ucspi-tcp (by bernstein) which can limit max number of concurrent connections. and includes tcp-wrappers functionality.
    1.15  
    1.16  
    1.17 -\name{Transport modules}, on the oppersite side of the system, are the modules to send outgoing mail; they are the interface between \name{queue-out} and remote hosts or local commands for further processing. The most popular ones are the \name{smtp} module (which acts as the \SMTP\ client) and the \name{pipe} module (to interface gateways to other systems or networks, like fax or uucp). A module for local delivery is not included, as it is in most other \MTA{}s; the reasons are described in FIXME.%fixme
    1.18 -Thus a \name{mail delivery agent} (like \name{procmail}) is to be used with the \name{pipe} module.
    1.19 +\name{Transport modules}, on the oppersite side of the system, are the modules to send outgoing mail; they are the interface between \name{queue-out} and remote hosts or local commands for further processing. The most popular ones are the \name{smtp} module (which acts as the \SMTP\ client) and the \name{pipe} module (to interface gateways to other systems or networks, like fax or uucp). A module for local delivery is not included, \masqmail\ passes this job to the \NAME{MDA} (see section \ref{sec:functional-requirements} for reasons). Thus a \name{mail delivery agent} (like \name{procmail}) is to be used with the \name{pipe} module.
    1.20  
    1.21  
    1.22  
    1.23  \subsubsection*{Inter-module communication}
    1.24  
    1.25 -Communication between modules is required to exchange data and status information. It is also called ``Inter-process communication'' (short: \NAME{IPC}), as modules are programs being part of a larger system, and processes are generally seen as programs in execution.
    1.26 +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.27  
    1.28 -The connections between \name{queue-in} and \name{scanning}, aswell as between \name{scanning} and \name{queue-out} is provided by the queues, only sending signals to trigger instant runs may be useful. Communication between receiving and transport modules and the outside world are done using the specific protocol they do handle.
    1.29 +The connections between \name{queue-in} and \name{scanning}, aswell 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.30  
    1.31 -Left is only communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Data is exchanged done using \unix\ pipes and a simple protocol is used.
    1.32 +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.33  
    1.34  \begin{figure}
    1.35  	\begin{center}
    1.36 -		\codeinput{input/ipc-protocol.txt}
    1.37 -		%\includegraphics[scale=0.75]{img/ipc-protocol.eps}
    1.38 +		\includegraphics[scale=0.75]{img/ipc-protocol.eps}
    1.39  	\end{center}
    1.40 -	\caption{State diagram of the protocol used for \NAME{IPC}}
    1.41 +	\caption{State diagram of the \NAME{IPC} protocol}
    1.42  	\label{fig:ipc-protocol}
    1.43  \end{figure}
    1.44  
    1.45 -% timing
    1.46 -One dialog consists of the four phases: connection attempt, acceptance reply, data transfer, success reply. The order is always the same. The connection attempt and data transfer are sent by the client process; replies are sent by the server process.
    1.47 -%fixme: split between header and data
    1.48 +\paragraph{Timing}
    1.49 +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.50  
    1.51 -% semantics
    1.52 -The connection attempt is simply opening the connection. This starts the dialog. A positive reply by the server leads to the data transfer, but a negative reply refuses the connection and resets both client and server to the state before the connection attempt. If the connection attempt was accepted, the client sends the data ending with a terminator sequence. When this terminator appears, the server process knows the complete data was transfered. The server process takes responsibility of the data in sending a positive success reply. A negative success reply resets both client and server to the state before the connection attempt.
    1.53 +\paragraph{Semantics}
    1.54 +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.55  
    1.56 -The data transfered needs to be of specific format. Used is the same format in which messages are spooled in the mail queues. See the following section for details. %fixme: check if it is the following section
    1.57 -%fixme: split between header and data
    1.58 +The client indicates the end of each data transfer with a special terminator sequence. The appearence 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.59  
    1.60 -% syntax
    1.61 -Data transfer is done sending plain text data. %fixme: utf8 ?
    1.62 -The terminator sequence used to indicate the end of the data transfer is a single dot on a line on its own. Line separators are the combination of \name{Carriage Return} and \name{Line Feed}, as it is used in various Internet protocols like \SMTP. Replys are one-digit numbers with \texttt{0} meaning success and any other number (\texttt{1}--\texttt{9}) indicate failure. %fixme: What are the octal values?
    1.63 -%fixme: split between header and data
    1.64 -
    1.65 -Figure \ref{fig:ipc-protocol} is a state diagram for the protocol.
    1.66 +\paragraph{Syntax}
    1.67 +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}''). Replys are one-digit numbers with \texttt{0} meaning success and any other number (\texttt{1}--\texttt{9}) indicate failure.
    1.68  
    1.69  
    1.70