#LyX 1.1 created this file. For more info see http://www.lyx.org/ \lyxformat 218 \textclass article \begin_preamble \@addtoreset{table}{section} \renewcommand{\thetable}{\thesection.\arabic{table}} \@addtoreset{figure}{section} \renewcommand{\thefigure}{\thesection.\arabic{figure}} \end_preamble \language english \inputencoding auto \fontscheme default \graphics default \float_placement !htbp \paperfontsize 10 \spacing single \papersize a4paper \paperpackage a4 \use_geometry 0 \use_amsmath 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation skip \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Title Concept paper for Monitas \layout Author from Stefan Hübner \newline and the Monitas Team \begin_float footnote \layout Standard Editor of this document is Stefan Hübner . Please send comments, extensions and proposals to him. \end_float \layout Date $Revision: 1.3 $, \begin_inset External Date,"","-I" \end_inset \layout Abstract This is a proposal how to design Monitas before actually start the coding. Collecting the ideas here will enforce to think about the structure before it is realized in code that cannot be modified later. With a little bit of luck this allows us to enhance Monitas' functionality quite easy in the future. And maybe we get a good user manual as side effect for free. \layout Abstract Revision 1.x of this \emph on concept \emph default paper is not describing the final version of the \emph on software \emph default that will be realized. It is loosely based on the existing alpha version\SpecialChar ~ 0.1 of Monitas and shall be a step by step approach towards Monitas version\SpecialChar ~ 0.99. If improvements to Monitas v0.x and this document will be in sync, we will have a good documentation of the internal system structure for Monitas\SpecialChar ~ v1.0 (and then this will be called Revision 2.0 of this document). So in general the major revision number of the concept paper is 1 higher than of the software, the minor revision numbers are both increasing but there is no connection between the values. \layout Standard \begin_inset LatexCommand \tableofcontents{} \end_inset \layout Section Basics \layout Standard Monitas is an extension to mondo/mindi to deal with remote backups between TCP/IP connected PCs. Monitas consists of two logical parts: a \emph on "client" \emph default that resides on the PC where the files (to backup/restore) are and a \emph on "server" \emph default on another (or the same) PC where the backup is stored. \layout Standard The backup may be written to/read from a CD, to a file on a hard-disk (or later to a revision controlled database). \layout Standard Both together, server and client, will handle the backup and restore process in the background. Each is controlled via a pipe to send commands and to get status information back (error messages, progress information). Though it is possible to trigger the backup/restore process with these interfaces, they are mainly designed for graphical (or text based) front-ends which can dock there to control the process and interact with the user. These front-ends aren't described here, but the syntax and semantics of the interfaces. \layout Standard We use a 1: \emph on n \emph default relation between the server and several clients on different PCs. That means there exists only one central server that serves all the clients out there. \layout Standard Even if this document distinguishes between \emph on server \emph default and \emph on client \emph default and the different roles they play for the backup process, it is possible that both parts use the same executable as both parts have much code in common. Like \emph on gzip \emph default , which is compressing when executed as \family typewriter gzip \family default and decompressing when executed as \family typewriter gunzip \family default , Monitas will run as server when executed as \family typewriter monitas_server \family default and will run as client when started as \family typewriter monitas_client \family default . \layout Section Requirements for Monitas \begin_inset LatexCommand \label{sec:Requirements} \end_inset \layout Standard This chapter contains the basic requirements for the client and the server part of Monitas. \layout Subsection Start a backup from client \layout Standard Necessary input: \layout Enumerate files to backup \layout Enumerate type of the backup (CD, ISO-file, ...) \layout Enumerate name of the backup (if not CD) \layout Enumerate compression (method, client or server-side) \layout Subsection Start a backup from the server \layout Standard Necessary input: \layout Enumerate client to address (IP address or name) \layout Enumerate files to backup \layout Enumerate type of the backup (CD, ISO-file, ...) \layout Enumerate name of the backup (if not CD) \layout Enumerate compression (method, client or server-side) \layout Subsection Restore a backup from client \layout Standard Necessary input: \layout Enumerate files to restore \layout Enumerate name/location of the backup (CD, ISO-file, ...) \layout Subsection Restore a backup from the server \layout Standard Necessary input: \layout Enumerate client to address (IP address or name) \layout Enumerate files to restore \layout Enumerate name/location of the backup (CD, ISO-file, ...) \layout Subsection Compare backup from client \layout Standard There are 2 reasons for a compares \layout Standard \SpecialChar ~ \SpecialChar ~ a) to guarantee the correct backup ( \begin_inset Quotes eld \end_inset \emph on verify \emph default \begin_inset Quotes erd \end_inset ) \layout Standard \SpecialChar ~ \SpecialChar ~ b) to find modifications of files since the last backup ( \begin_inset Quotes eld \end_inset \emph on compare \emph default \begin_inset Quotes erd \end_inset ) \layout Standard In case a) we must do a bit-compare between original files and their (decompress ed) backup, in case b) it's sufficient to generate hash values of every original file and its backuped counterpart and compare the hashes (less network traffic). \layout Standard To distinguish the different intentions, we call the comparison a) \emph on Verify \emph default as it's normally started directly after a backup, and call the case b) \emph on Compare \emph default as it is triggered to recognize modifications (perhaps to generate an increment al backup). \layout Standard Necessary input: \layout Enumerate name of the backup \layout Enumerate mode of compare [a) or b)] \layout Enumerate files to compare [mode b) only; mode a) will always compare all files in the backup] \layout Subsection Compare from the server \layout Standard Necessary input: \layout Enumerate client to address (IP address or name) \layout Enumerate name of the backup \layout Enumerate mode of compare [a) or b), the modes were described in previous sub-chapter] \layout Enumerate files to compare [mode b) only; mode a) always compares all files in the backup] \layout Section System structure \begin_inset LatexCommand \label{sec:SystemStructure} \end_inset \layout Standard Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:SystemStructure} \end_inset gives an overview about the general structure of Monitas. Monitas' functionality is mainly split into 2 independent parts: a \emph on client \emph default component on the PC where files are backuped or restored, and a \emph on server \emph default component to write the backup on an external medium or read previous backups from an external medium. \layout Standard Both parts base on mondo/mindi for accessing files, doing (de)compression, creating ISO-files, writing them to CD/DVD, \SpecialChar \ldots{} \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 173 file diagrams/systemoverview.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:SystemStructure} \end_inset System structure \end_float \layout Standard \added_space_top 0.3cm At startup, a client connects to the server process to establish the connection: The client uses a predefined ( \begin_inset Quotes eld \end_inset well known \begin_inset Quotes erd \end_inset ) port where the server is listening. When receiving a message at this port the server duplicates itself by using the system call \family typewriter fork() \family default or \family typewriter clone() \family default . The child process will serve the connecting client on a new allocated port and the parent process will continue waiting for further clients. \layout Standard By that mechanism we need only one predefined port number and only on the server PC. Details in the next chapter. \layout Section Message Flows \layout Standard This chapter describes the information flow between Monitas' structural parts. The flows are designed to fulfill the requirements of chapter\SpecialChar ~ \begin_inset LatexCommand \ref{sec:Requirements} \end_inset . \layout Subsection Flows between Server and Client ( \emph on IFcs \emph default and \emph on IFsc \emph default ) \layout Subsubsection Connection Establishment \layout Standard Before any backup/restore can start, \emph on client \emph default and \emph on server \emph default must introduce each other. This message flow between (each) client process and the server (parent) process only takes place when a client process is started. The client calls the server to tell him "Here am I" whereupon the server is doubling itself via the \family typewriter fork() \family default system call. The new created child of the server process will serve the new connected client from now on, while the parent process of the server continues waiting for other clients to connect. The connecting procedure is shown in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:ClientConnect} \end_inset . \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 260 file diagrams/connect_client.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:ClientConnect} \end_inset A client connects to the server process \end_float \layout Subsubsection Backup and Restore Process \layout Standard The backup and restore procedures are handled between the client and its corresponding child of the server process. Both, backup and restore may be triggered from server or from client side. The message flow between server and client for the backup process is shown in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:BackupClientServer} \end_inset . \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 329 file diagrams/backup_client_server.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:BackupClientServer} \end_inset Message flow for Backup \end_float \layout Standard The restore procedure shown in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:RestoreClientServer} \end_inset is very similar. It may be triggered either from server or from client side, too. \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 355 file diagrams/restore_client_server.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:RestoreClientServer} \end_inset Message flow for Restore \end_float \layout Subsubsection Connection Termination \layout Standard When a client has done its job or some errors occurred (or maybe the server wants to stop running or \SpecialChar \ldots{} ) the connection can be shutdown in the way that Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:DisconnectServerClient} \end_inset shows. \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 362 file diagrams/disconnect_client_server.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:DisconnectServerClient} \end_inset Terminating the connection between server and client \end_float \layout Subsubsection List backups \layout Standard Before restoring files, a client can inquire the server which backups are available. Since there are several locations where the server may store a backup (on CD, in local file(s), (in the future: in a database,) \SpecialChar \ldots{} ) the client can use the message flow defined in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:ListBackupsClientServer} \end_inset to get a list of all (for this client) accessible backups. \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 135 file diagrams/list_backups_client_server.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:ListBackupsClientServer} \end_inset Get list of accessible backups from server \end_float \layout Subsubsection List content of a backup \layout Standard When doing a \emph on nuke restore \emph default it's sufficient to address a total backup. But in all other cases you want to know which files are in the backup, what their sizes, modification dates are and what other info is available. To inquire the content of a specific backup file, the client uses the flows in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:ListBackupcontentClientServer} \end_inset . \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 135 file diagrams/list_backupcontent_client_server.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:ListBackupcontentClientServer} \end_inset Get content of a specific backup from server \end_float \layout Subsection Message Flows between Client and (Graphical)User-Interface ( \emph on IFcg \emph default ) \begin_inset LatexCommand \label{sec:GuiClient} \end_inset \layout Standard To interact with the client process running silently in the background, the client sets up a named pipe when it starts. A Graphical User Interface (GUI) can dock to that pipe and control the client. \layout Standard The messages sent through the pipe are text based commands, so the most primitive user interface will be a console with I/O redirect to the pipe. \layout Standard The predefined commands are shown in Chapter\SpecialChar ~ \begin_inset LatexCommand \ref{sec:GuiCommands} \end_inset . \layout Subsubsection (Re-)Connect to a server \begin_inset LatexCommand \label{sec:GuiClientConnect} \end_inset \layout Standard Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:GuiClientConnect} \end_inset shows how the connection between a client and the server is established from the Client GUI. If there exists a previous connection, that connection is closed before building up the new one, as every client can be connected to \emph on one \emph default server only at the same time. \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 152 file diagrams/connect_GUI_client.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:GuiClientConnect} \end_inset Enable Connection from Client GUI \end_float \layout Subsubsection Start a Backup \layout Standard When starting a backup, the client needs to know which files to backup and some information about the backup itself: what type of backup (boot-able CD-ROM, ISO-File,\SpecialChar \ldots{} ), the name/location (/dev/cdwriter, /usr/bkup/file.tgz,\SpecialChar \ldots{} ) and the mode of the backup (compress_clientside=gzip,\SpecialChar \ldots{} ). The message flow is in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:GuiClientBackup} \end_inset . \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 200 file diagrams/backup_GUI_client.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:GuiClientBackup} \end_inset Start Backup from Client GUI \end_float \layout Subsubsection Start a Restore \layout Standard If a client knows (by other procedures, see chapter\SpecialChar ~ \begin_inset LatexCommand \ref{sec:GuiClientListBackups} \end_inset and \begin_inset LatexCommand \ref{sec:GuiClientListBackupContent} \end_inset ) that a certain backup exists on the server (and the client may access it), it can start restoring specified files like shown in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:GuiClientRestore} \end_inset . The files can be addressed by their exact path/name (as stored in the backup) or as wildcards (path/* or path/name* -- may be extended in the future). \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 239 file diagrams/restore_GUI_client.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:GuiClientRestore} \end_inset Start Restore from Client GUI \end_float \layout Subsubsection Get list of previous, accessible Backups \begin_inset LatexCommand \label{sec:GuiClientListBackups} \end_inset \layout Standard To get a list of available backups the client must ask the server which are available (maybe specific to the requesting client/user). The message flow is in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:GuiClientListBackups} \end_inset . \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 104 file diagrams/list_backups_GUI_client.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:GuiClientListBackups} \end_inset Ask Server for available backups \end_float \layout Subsubsection Get content (files) of a specified Backup \begin_inset LatexCommand \label{sec:GuiClientListBackupContent} \end_inset \layout Standard The client knows (maybe via the flow in Chapter\SpecialChar ~ \begin_inset LatexCommand \ref{sec:GuiClientListBackups} \end_inset ) which backup(s) are available at the server. To view the content (the file names, -sizes,\SpecialChar \ldots{} ) of a specific backup the client can ask the server to deliver this information. The message flow is shown in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:GuiClientListBackupContent} \end_inset . \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 104 file diagrams/list_backupcontent_GUI_client.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:GuiClientListBackupContent} \end_inset Ask Server for the content of a backup \end_float \layout Subsubsection Start a Verify \layout Standard \layout Subsubsection Start a Compare \layout Standard \layout Subsubsection Terminate Client \layout Standard It doesn't make sense to close the client-server connection without terminating the client. Either the client must be connected to another server (procedure see chapter\SpecialChar ~ \begin_inset LatexCommand \ref{sec:GuiClientConnect} \end_inset ) if it shall do other backups/restores or the client just keeps connected to the same server (so no changes are necessary :-). Nevertheless if the client has done its job, it must be shutdown but that concerns both, the connection and the client . This procedure is shown in Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:GuiClientTerminate} \end_inset . \layout Standard Of course you can simply close the GUI of the client. But this won't have any influence to the running client\SpecialChar \ldots{} \layout Standard \begin_float fig \layout Standard \align center \begin_inset Figure size 238 141 file diagrams/terminate_GUI_client.eps width 4 80 flags 10 \end_inset \layout Caption \begin_inset LatexCommand \label{fig:GuiClientTerminate} \end_inset Terminate the client \end_float \layout Subsection Message Flows between Server and (Graphical)User-Interface ( \emph on IFsg \emph default ) \layout Standard Ideas: \layout Description N.N. All backup/verify/compare/restore procedures that can be triggered from client side, too. \layout Description Status Show all current connections and its current status (activity). \layout Description Monitor Request server to generate (continuous) progress messages to a specified connection. \layout Description Info Server notifies the user about internal processes. \layout Description Verbose Modify the level of server's verbosity. \layout Subsection Message Flows between Server and its Child ( \emph on IFss \emph default and \emph on IFsm \emph default ) \layout Standard Ideas: \layout Description GetClientInfo Server asks server child for info about the connection to a client (IP:port, current activity). \layout Description TerminateConnection Server asks server child to terminate the connection. \layout Description TerminateNotification Server child notifies the parent server that it will terminate now. \layout Description N.N. All backup/verify/compare/restore procedures that are requested to the server, but must be executed from a server's child. \layout Section Interfaces \layout Standard Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:SystemStructure} \end_inset in Section\SpecialChar ~ \begin_inset LatexCommand \ref{sec:SystemStructure} \end_inset (System Structure) names the defined interfaces in respect of their location. E.g. the interface between the server and the client is called \emph on IFcs \emph default if you see it as part of the client, and it's called \emph on IFsc \emph default if it is described as part of the server. This naming is continued in the software, but of course the 2 parts must fit together to transmit the information. \layout Standard To describe this common part (e.g. the format of the data structures) we introduce a second naming scheme here that denominates the matter inbetween. These names are used in the sources, too. So pay attention to understand the difference: The common parts of the interfaces are named \emph on Ixx \emph default , their realization at the two ends are named \emph on IFxy \emph default . \layout Standard \begin_float tab \layout Standard \begin_inset Tabular \begin_inset Text \layout Standard \series bold Interface \end_inset \begin_inset Text \layout Standard \series bold is connecting \end_inset \begin_inset Text \layout Standard \emph on Im \emph default ("Mondo") \end_inset \begin_inset Text \layout Standard server/client internally with mondo \end_inset \begin_inset Text \layout Standard \emph on In \emph default ("Network") \end_inset \begin_inset Text \layout Standard client and server, \emph on IFcs <--> \emph default \emph on IFsc \end_inset \begin_inset Text \layout Standard \emph on Ipc \emph default ("Pipe in Client") \end_inset \begin_inset Text \layout Standard client to GUI, \emph on IFcg <--> \emph default external \end_inset \begin_inset Text \layout Standard \emph on Ips \emph default ("Pipe in Server") \end_inset \begin_inset Text \layout Standard server to GUI, \emph on IFsg \emph default <--> external \end_inset \begin_inset Text \layout Standard \emph on Is \emph default ("Server interprocess") \end_inset \begin_inset Text \layout Standard Server's parent instance with the child instances, \emph on IFss \emph default <--> \emph on IFsm \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{tab:Interfaces} \end_inset Interfaces \end_float \layout Subsection Interface \emph on Im \emph default to Mondo \layout Standard \layout Subsubsection \emph on Im \emph default in Server \layout Subsubsection \emph on Im \emph default in Client \layout Subsection Interface \emph on In \emph default between Client and Server \layout Standard \layout Subsection Interface \emph on Ipc \emph default , Client's pipe to the GUI \layout Standard \layout Subsection Interface \emph on Ips \emph default , Server's pipe to the GUI \layout Standard \layout Subsection Interface \emph on Is \emph default , IPC of server instances \layout Standard \layout Section Commands at the GUI interfaces \begin_inset LatexCommand \label{sec:GuiCommands} \end_inset \layout Standard To interact from a Graphical User Interface (GUI) to the server or client process running locally, silently in the background, every client and the server (parent process) sets up a named pipe when it starts. A Graphical User Interface (GUI) can dock to that pipe and control the client/server. \layout Standard If not otherwise specified, the server's pipe is \family typewriter /var/run/monitas/server \family default and a client's pipe is \family typewriter /var/run/monitas/client_ \emph on nnn \family default \emph default with \family typewriter \emph on nnn \family default \emph default depends upon the current connection. \layout Standard (For IPv4 we could use the server's IP:port, e.g. \family typewriter client_192168001001-22345 \family default i.e. 12-digits IP address, dash, 5-digits port of the server's child for that connection). \layout Standard This allows us to run more than one client on a PC (maybe more than 1 user is logged in) that can be connected to the same server (IP address) with different ports (server's child's port number) or to different servers (different IP addresses). Only one server per PC is allowed, but it can handle several connections in parallel (by several child processes). In most cases, the backup medium is a very limiting resource (only 1, 2\SpecialChar \ldots{} CD-Writer, Tape-Streamer, Database, \SpecialChar \ldots{} ) that can be managed much easier by one central instance. Otherwise we had to expand the resource management (that is already necessary between parent server and child processes) with more danger to run into dead-locks, race-conditions and other difficult-to-debug stuff. \layout Standard If not denoted otherwise, the description in this chapter is valid for the messages at the client GUI \emph on and \emph default the messages at the server GUI. \layout Subsection Message Structure \layout Standard The messages sent through the pipe are text based commands, so the most primitive user interface will be a console with I/O redirect to the pipe. \layout Standard The used semantic is: \layout Standard \family typewriter COMMAND [ARG [\SpecialChar \ldots{} ]] \backslash n \layout Standard where \layout Itemize COMMAND is a predefined (case insensitive) command, valid chars: [a-zA-Z] \layout Itemize ARG is zero or more arguments for COMMAND, each COMMAND has a predefined number of mandatory arguments (some command additional might have optional arguments) \layout Itemize COMMAND and ARG is separated by one space (\SpecialChar ~ ) \layout Itemize ARGs are separated by one space (\SpecialChar ~ ) \layout Itemize ARGs contain of at least one printable character and/or whitespace ([ \backslash t \backslash n]) \layout Itemize an ARG that contains spaces must be surrounded by '\SpecialChar \ldots{} ' or \begin_inset Quotes eld \end_inset \SpecialChar \ldots{} \begin_inset Quotes erd \end_inset \layout Itemize inside '\SpecialChar \ldots{} ' following characters must be escaped by a backslash ( \backslash ) for their literal meaning: \begin_deeper \layout List \labelwidthstring 00.00.0000 \backslash ' for literal single quote (') \layout List \labelwidthstring 00.00.0000 \backslash \backslash for the backslash ( \backslash ) itself \layout Standard to use as one argument use \family typewriter 'c: \backslash \backslash stefan \backslash 's\SpecialChar ~ \begin_inset Quotes eld \end_inset quote \begin_inset Quotes erd \end_inset ' \end_deeper \layout Itemize inside \begin_inset Quotes eld \end_inset \SpecialChar \ldots{} \begin_inset Quotes erd \end_inset you must not use the double quote character ( \begin_inset Quotes eld \end_inset )! \newline There is no escape sequence defined for a literal meaning! Surprised? But this kind of definition allows us to use the ARG without further modification by simply surrounding it with double quotes: \family typewriter \begin_inset Quotes eld \end_inset c: \backslash hugo\SpecialChar ~ rabson's\SpecialChar ~ dir \backslash file.c \begin_inset Quotes erd \end_inset \layout Itemize if the ARG itself shall begin with a double quote ( \begin_inset Quotes eld \end_inset ) or single quote (') then quote the whole argument with '\SpecialChar \ldots{} ' (and escape the ' at the beginning). \layout Itemize if the ARG doesn't contain spaces but contains any quote character(s), you needn't do anything \layout Itemize COMMAND line is terminated by a newline character(' \backslash n'), an optional ASCII-Null (' \backslash 0') can follow \layout Standard Possible, future extension: \layout Itemize Using ' \backslash 0' instead of '\SpecialChar ~ ' to separate ARGs (and COMMAND) will dispense with the nasty space quoting. The end of the command line is then marked by two ' \backslash 0' instead of ' \backslash n'. To distinguish between old and new syntax, the client can look at the first character behind the COMMAND: if it's a ' \backslash 0' the GUI uses the new syntax and all responses to the COMMAND use the new syntax, too. If the character is a space '\SpecialChar ~ ' or newline ' \backslash n' we answer in old (above described) syntax and must pay attention to the quoting \layout Subsection Implementation Detail \layout Standard There is much work that is common to all the pipe interfaces that use text based messages: extract the command, calculate the number of mandatory parameters, split the arguments, parse for escape sequences, check if an arguments fits the requested type (e.g. filename, IP address, port number,\SpecialChar \ldots{} ), translate the textual argument into its machine readable format, \SpecialChar \ldots{} And equivalent steps are necessary when we want to create and send a message. And different commands use the same argument types that always must be parsed and checked in the same way. \layout Standard At the moment the extent of the complete command set cannot be given, so it would be the best to keep yet unknown extensions in mind and implement the pipe interface as a generic one: \layout Itemize use tables for valid commands (different tables for server- and client-pipes [or flags in a common table to ease common syntax for equivalent server/client commands?]) \layout Itemize each \begin_inset Quotes eld \end_inset command \begin_inset Quotes erd \end_inset entry contains the number of mandatory and optional arguments \layout Itemize each argument refers to a predefined type (not only \emph on int \emph default , \emph on string \emph default but of finer granularity like \emph on filename \emph default , \emph on dirname \emph default , \emph on devicename \emph default , \emph on backupname \emph default , \emph on portnumber \emph default , \SpecialChar \ldots{} ) that can be generated and checked for validity by generic routines. \layout Standard The tables can easily be extended and new commands can introduced with less effort by reusing existing subroutines for the argument handling. (B.t.w. the table contains all information that is necessary for an generic help function to each defined message.) Of course this only concerns the interface handling, not the new functionality. But why reinvent the wheel twice? \layout Subsection Defined Commands \layout Standard Table\SpecialChar ~ \begin_inset LatexCommand \ref{tab:GuiCommands} \end_inset shows the defined commands to the GUI. \layout Standard Currently there are only the messages from Figure\SpecialChar ~ \begin_inset LatexCommand \ref{fig:GuiClientConnect} \end_inset and \begin_inset LatexCommand \ref{fig:GuiClientBackup} \end_inset entered in this table. But we recognize that the messages \family typewriter notconnected \family default , \family typewriter abort \family default and \family typewriter backupdone \family default serve the same purpose. We should think about, if we want a streamline small interface (replace the 3 messages by one) or accept the redundancy. Perhaps that depends on the connected GUI. A simple command line interface (that transfers the messages transparently to the user) benefits from the different message names, a graphical user interface on the other side must join the different messages to the same \begin_inset Quotes eld \end_inset Not Done! Error \begin_inset Quotes erd \end_inset requestor. \layout Standard \begin_float tab \layout Standard \begin_inset Tabular \begin_inset Text \layout Standard If (from/ \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard No of args \end_inset \begin_inset Text \layout Standard type of \end_inset \begin_inset Text \layout Standard type of \end_inset \begin_inset Text \layout Standard type of \end_inset \begin_inset Text \layout Standard type of \end_inset \begin_inset Text \layout Standard type of \end_inset \begin_inset Text \layout Standard /to GUI) \end_inset \begin_inset Text \layout Standard Command \end_inset \begin_inset Text \layout Standard (mnd/opt) \end_inset \begin_inset Text \layout Standard arg 1 \end_inset \begin_inset Text \layout Standard arg 2 \end_inset \begin_inset Text \layout Standard arg 3 \end_inset \begin_inset Text \layout Standard arg 4 \end_inset \begin_inset Text \layout Standard arg 5 \end_inset \begin_inset Text \layout Standard C/- \end_inset \begin_inset Text \layout Standard \family typewriter connect \end_inset \begin_inset Text \layout Standard 1/1 \end_inset \begin_inset Text \layout Standard ServerIP \end_inset \begin_inset Text \layout Standard Port \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard -/C \end_inset \begin_inset Text \layout Standard \family typewriter disconnected \end_inset \begin_inset Text \layout Standard 2/0 \end_inset \begin_inset Text \layout Standard ServerIP \end_inset \begin_inset Text \layout Standard Port \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard -/C \end_inset \begin_inset Text \layout Standard \family typewriter connected \end_inset \begin_inset Text \layout Standard 0 \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard -/C \end_inset \begin_inset Text \layout Standard \family typewriter notconnected \end_inset \begin_inset Text \layout Standard 1/1 \end_inset \begin_inset Text \layout Standard ErrNo \end_inset \begin_inset Text \layout Standard ErrorMsg \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard C/- \end_inset \begin_inset Text \layout Standard \family typewriter backup \end_inset \begin_inset Text \layout Standard 4/* \end_inset \begin_inset Text \layout Standard Bkup type \end_inset \begin_inset Text \layout Standard name \end_inset \begin_inset Text \layout Standard mode \end_inset \begin_inset Text \layout Standard filepattern \end_inset \begin_inset Text \layout Standard \SpecialChar \ldots{} \end_inset \begin_inset Text \layout Standard -/CS \end_inset \begin_inset Text \layout Standard \family typewriter progress \end_inset \begin_inset Text \layout Standard 1/0 \end_inset \begin_inset Text \layout Standard percent \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard -/CS \end_inset \begin_inset Text \layout Standard \family typewriter abort \end_inset \begin_inset Text \layout Standard 1/1 \end_inset \begin_inset Text \layout Standard ErrNo \end_inset \begin_inset Text \layout Standard ErrorMsg \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard -/C \end_inset \begin_inset Text \layout Standard \family typewriter backupdone \end_inset \begin_inset Text \layout Standard 1/1 \end_inset \begin_inset Text \layout Standard ErrNo \end_inset \begin_inset Text \layout Standard ErrorMsg \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \SpecialChar \ldots{} \end_inset \begin_inset Text \layout Standard Table \end_inset \begin_inset Text \layout Standard is not \end_inset \begin_inset Text \layout Standard complete \end_inset \begin_inset Text \layout Standard \SpecialChar \ldots{} \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{tab:GuiCommands} \end_inset Commands at the GUI Interfaces \end_float \layout Section Open Issues \layout Standard Here I collect all the ideas that need further analysis. Some solutions may be written here if they might have side effects to the system, I must think about. Or if I hadn't have the time to insert them at the correct place ;-) \layout Itemize How to realize the daemon for client and server side? \begin_deeper \layout Standard It should dock to the pipe between the GUI and the process, so it can monitor if there is something going on, and if not it can do its job. \layout Standard If a daemon triggered backup is running, no user interaction is possible, so no mix up between two backups can happen. \end_deeper \layout Itemize Security \begin_deeper \layout Standard What should the user be allowed? Start backups? If yes, what files? Only files, he has access to, to prevent snooping system information. \layout Standard Show contents of other backups? \layout Standard Restore files? From which backups? To which destinations? \layout Standard Backup to CD? Necessary rights to write there? Maybe handled by mondo. \layout Standard Shall the client always run as root (to access all, if triggered from outside)? If yes, how assure that no unprivileged user will abuse this? \layout Standard Shall server run as root? Server child with lower privilege? Same as user on client side - but then how to realize - user id's from client mustn't exist on server. \end_deeper \layout Itemize Use a secure tunnel as connection? How to establish/address tunnel? \layout Subsection Possible Extensions \layout Itemize Wildcards for specifying which files to backup/restore \begin_deeper \layout Itemize Step 1: Standard UNIX Expressions `*' `?' for filenames not only at the end of the name \layout Itemize Step 2: also for directories (Q: does `/*/readme' match e.g. \newline `/usr/local/share/packet/readme'?) \layout Itemize Step 3: Regular Expressions (User has circumvent above question) \end_deeper \layout Itemize Distinguish between restore (files are written to their old places) and extract (new destination for file(s) possible). \the_end