docs/diploma: thesis/tex/5-Improvements.tex comparison

comparison thesis/tex/5-Improvements.tex @ 337:3f5088841807

reordered two subsubsections

author	meillo@marmaro.de
date	Sun, 25 Jan 2009 20:31:54 +0100
parents	100efdd32ea5
children	a13392b4fee8

comparison

equal deleted inserted replaced

-:8fa374b3f415
+:3f5088841807
 \name{Transport modules}, on the opposite 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 \NAME{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.
-\subsubsection*{Inter-module communication}
-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.
-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.
-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.
-\begin{figure}
-	\begin{center}
-		\includegraphics[scale=0.75]{img/ipc-protocol.eps}
-	\end{center}
-	\caption{State diagram of the \NAME{IPC} protocol}
-	\label{fig:ipc-protocol}
-\end{figure}
-\paragraph{Timing}
-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.
-\paragraph{Semantics}
-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.
-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.
-\paragraph{Syntax}
-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.
 \subsubsection*{The queue}
 The queue is actually two queues and a data pool. The queues store the spool files---unprocessed in \name{incoming} and in complete and valid form in \name{outgoing}. The \name{pool} is the storage of data files, the message bodies of queued messages.
 %\end{figure}
 %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.
 A sample spool file. With comments in parenthesis.
 \codeinput{input/sample-spool-file.txt}
+\subsubsection*{Inter-module communication}
+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.
+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.
+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.
+\begin{figure}
+	\begin{center}
+		\includegraphics[scale=0.75]{img/ipc-protocol.eps}
+	\end{center}
+	\caption{State diagram of the \NAME{IPC} protocol}
+	\label{fig:ipc-protocol}
+\end{figure}
+\paragraph{Timing}
+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.
+\paragraph{Semantics}
+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.
+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.
+\paragraph{Syntax}
+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.
 \subsubsection*{Rights and permission}

Mercurial > docs > diploma

comparison thesis/tex/5-Improvements.tex @ 337:3f5088841807