[Anet-checkins] CVS: Documentation/design/latex anetdesign.tex,1.1,1.2

[Christopher J. <cwj...@us...>]

Update of /cvsroot/anet/Documentation/design/latex
In directory usw-pr-cvs1:/tmp/cvs-serv31623

Modified Files:
	anetdesign.tex 
Log Message:
Added Section 2.
The document went throught a lot of changes. I use article now, I
don't like the chapter headings from the report document class. We'll
see how things go. There's still a lot of things I need to touch up. I
think I want to add the introduction to anet stuff inside the
document because some of the cross references won't make sens otherwise.

Index: anetdesign.tex
===================================================================
RCS file: /cvsroot/anet/Documentation/design/latex/anetdesign.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** anetdesign.tex	2001/12/29 00:40:29	1.1
--- anetdesign.tex	2002/01/01 18:46:10	1.2
***************
*** 21,28 ****
  %=====================================================================%
  
! \documentclass[letterpaper]{report}
  \usepackage{latexsym}   % Use special symbols.
  \usepackage{makeidx}    % Make an index.
! \usepackage{url} \usepackage{appendix}
  %\usepackage{fancyhdr}
  %\usepackage{pandora}    % use the pandora fonts, they seem more modern
--- 21,29 ----
  %=====================================================================%
  
! \documentclass[letterpaper]{article}
  \usepackage{latexsym}   % Use special symbols.
  \usepackage{makeidx}    % Make an index.
! \usepackage{url} 
! \usepackage{appendix}
  %\usepackage{fancyhdr}
  %\usepackage{pandora}    % use the pandora fonts, they seem more modern
***************
*** 41,44 ****
--- 42,46 ----
  \parskip 1.5ex plus 1ex minus 0.5ex
  %\parindent      0em
+ 
  % Let Latex write the pages headings.
  \pagestyle{headings}
***************
*** 55,58 ****
--- 57,71 ----
  \newcommand{\la}{\mathopen{<}} \newcommand{\ra}{\mathopen{>}}
  
+ %environment used for the DTD's
+ \newsavebox{\fmbox}
+ \newenvironment{fmpage}[1]
+ {\begin{lrbox}{\fmbox}\begin{minipage}{#1}}
+ {\end{minipage}\end{lrbox}\fbox{\usebox{\fmbox}}}
+ 
+ % \newsavebox{\fmbox}
+ % \newenvironment{fmpage}[1]
+ % {\begin{lrbox}{\fmbox}\begin{minipage}{#1}}
+ % {\end{minipage}\end{lrbox}\fbox{\usebox{\fmbox}}}
+ 
  \newcounter{exnum}
  \newenvironment{example}[1]{\penalty-2000\vskip1.5\parskip
***************
*** 72,94 ****
  \begin{document}
  \maketitle
  \tableofcontents
! \listoffigures \listoftables
! 
! \begin{abstract}
! Blah Blah put all the ANet abstract here.
! \end{abstract}
! 
! % Since I wanted an appendix and I thought we would combine both h-l &
! % l-l designs, I thought we would need more sectionning, thus came the
! % report document style and the \part.  The problem is the \part
! % sectionning does not affect the counter in the table of contents,
! % resulting with section numbers 0.1, 0.2.  In reports only the
! % the level above \section is \chapter.  But the \chapter command makes
! % a big bold chapter heading like in a book ( we don't want that).  
! % Anyways I'm leaving it  there for the time being.  I'll try to
! % figure something out later.
! 
! \setcounter{chapter}{1}
! \part{High-Level Design} \label{part:hld} \index{high-level design}
  This is the High-Level Design for ANet.  It presents a non-technical
  view of the different components of ANet, how they work, how they
--- 85,100 ----
  \begin{document}
  \maketitle
+ \clearpage
+ \pagenumbering{roman}
  \tableofcontents
! \listoffigures 
! \listoftables
! %do we need an abstract?
! %\clearpage
! %\begin{abstract}
! %Blah Blah put all the ANet abstract here.
! %\end{abstract}
! \clearpage
! \pagenumbering{arabic}
  This is the High-Level Design for ANet.  It presents a non-technical
  view of the different components of ANet, how they work, how they
***************
*** 116,120 ****
  direction.
  
! \subsubsection{What is a Module?}
  A module is an isolated group of code that can have one or more
  running instances in the ANet daemon.  It is isolated by not being
--- 122,126 ----
  direction.
  
! \subsubsection{What is a Module?} \index{module}
  A module is an isolated group of code that can have one or more
  running instances in the ANet daemon.  It is isolated by not being
***************
*** 177,181 ****
  memory, mark it as temporary so its memory could be freed if memory is
  tight, and so on.\footnote{This was ``inspired'' by, you know
! \ldots\cite{macmem}}
  
  Second, whenever a function in a module is called, the module instance
--- 183,187 ----
  memory, mark it as temporary so its memory could be freed if memory is
  tight, and so on.\footnote{This was ``inspired'' by, you know
! \ldots\cite{applemem}}
  
  Second, whenever a function in a module is called, the module instance
***************
*** 194,199 ****
  system:
  \begin{description}
!        \item Files: create, open, read, write, close and delete.
!        \item Directories: create, read, delete
  \end{description}
  Once opened, files and directories are identified by an ID.  The files
--- 200,205 ----
  system:
  \begin{description}
!        \item[Files]: create, open, read, write, close and delete.
!        \item[Directories]: create, read, delete
  \end{description}
  Once opened, files and directories are identified by an ID.  The files
***************
*** 203,207 ****
         \item[UNIX] \verb|/directory/directory/.../file.| \\Up one directory: ..
         \item[MacOS] \verb|Disk:folder:folder:...:file.| \\Up one directory: ::
!        \item[Win32] \verb|Disk:\directory\directory\...\file.ext.| \\Upone directory: ..
  \end{description}
  
--- 209,213 ----
         \item[UNIX] \verb|/directory/directory/.../file.| \\Up one directory: ..
         \item[MacOS] \verb|Disk:folder:folder:...:file.| \\Up one directory: ::
!        \item[Win32] \verb|Disk:\directory\directory\...\file.ext.|\\Up one directory: ..
  \end{description}
  
***************
*** 270,276 ****
  information through function calls in ways that are not explicitly
  required by the wrapper.  Basically, an instance tells the wrapper ``I
! want to call function X with arguments Y in module instance M''.
! Then, the wrapper will call a function in M that will return true only
! if, for the given information from the calling instance, M accepts to
  get called by the other module.  Then, if that's the case, then
  function will be called with the arguments.
--- 276,282 ----
  information through function calls in ways that are not explicitly
  required by the wrapper.  Basically, an instance tells the wrapper ``I
! want to call function $X$ with arguments $Y$ in module instance $M$''.
! Then, the wrapper will call a function in $M$ that will return true only
! if, for the given information from the calling instance, $M$ accepts to
  get called by the other module.  Then, if that's the case, then
  function will be called with the arguments.
***************
*** 302,313 ****
  \subsection{DTD}
  See the complete DTD for more information see \xs{sec:dtd}.
  \begin{verbatim}
! <!-- Root element --> <!ELEMENT ANet (ClientConnection)+, BandwidthManager, (ClusterGroup)+, CoreModules, (Cluster)+>
  <!ATTLIST ANet %security;>
  \end{verbatim}
  
  \section{Client Connection Modules} \label{sec:ccm}
! Communication bridge between the ANet daemon and the clients.
  
  \section{Data Transformation Modules} \label{sec:dtm}
  Transform some data.
--- 308,498 ----
  \subsection{DTD}
  See the complete DTD for more information see \xs{sec:dtd}.
+ 
+ \begin{figure}[!h]
+ \begin{fmpage}{\textwidth}
  \begin{verbatim}
! <!-- Root element -->
! <!ELEMENT ANet (ClientConnection)+, BandwidthManager, (ClusterGroup)+, CoreModules,
!  (Cluster)+>
  <!ATTLIST ANet %security;>
  \end{verbatim}
+ \end{fmpage}
+ \caption{The Run Time Wrapper DTD} \label{fig:rtwdtd}
+ \end{figure}
  
  \section{Client Connection Modules} \label{sec:ccm}
! The Client Connection Modules act as a communication bridge between
! the various programs that use the ANet networks (the clients) and the
! program that manages the network (the ANet daemon).
! 
! \subsection{Design}
! \subsubsection{Clients and Daemon}
! From the point of view of its architecture, ANet is actually several
! programs. Only one program manages the network: the ANet
! daemon\footnote{You can have more than one ANet daemon in the same
! machine, but why? ANet is flexible enough to allow isolated network to
! coexist in the same system.}. It is consisting of the run-time wrapper
! \xs{sec:rtw} and of different modules. The daemon itself does not
! ``use'' the network. The programs that want to use an ANet network
! will have to communicate with the daemon in order to do so.  Those
! programs are the ANet Clients.
! 
! The major advantage of doing so is that each time a developer wants to
! implement a new application for an anonymous network, that person does
! not need to re-implement the entire protocol again. This is similar to
! TCP, since it is being implemented in the operating system, the
! programmers won't have to re-implement TCP for each program that will
! be using it.
! 
! \subsubsection{Services}
! Since ANet is a protocol, it doesn't know what kind of data it is
! distributing. So, the same network could be used for completely
! different things, yet it is not aware of it.
! 
! But then, the clients ultimately care about what kind of data they are
! going to send and receive. As a result, each packet of information
! will be identified by a Service Number. A Service is a specific use of
! the network, and as a result, a group of information that can be
! consistently created, analyzed and modified. This is similar to a
! "port" in IP\cite{uscip}.
! 
! \subsubsection{Interaction Summary}
! The Clients Connection Modules are modules that fully represent, by
! themselves, entire clients. Downwards \xs{sec:rtw}, they receive
! commands\footnote{This what inspired by HyperTalk, the programming
! language of HyperCard\cite{applehyp}. Here's an example: ask "What is your name?"
! if the result is "Benad" then answer "Wow! I have the same name!"
! Here, "ask" and "answer" are commands, while "the result" is a
! function and "is" is an operator. This is not a joke!  } from the
! clients and they transfer them downwards in the daemon. Upwards
! \xs{sec:rtw}, they receive relevent data from the rest of the daemon
! and they tranfer that data to the proper clients.
! 
! Here is a summary of the interaction between a client, its client
! connection module and the daemon within a session, from a high-level
! point of view.
! 
! \begin{itemize}
! \item The user starts the ANet daemon. Thus, the clent connection
! module is started.
! \item The user starts the ANet client.
! \item The client connects itself to the client connection module.
! \item The client registers the services it will use. The client can
! receive and send data only for the services it registered for.
! \item The client connection module sends those registration requests
! to the rest of the daemon. Registration is actually made for the
! client connection module, so if more than one client connect to the
! module, then it has to remember which client requested what services.
! \item The client starts sending some commands to the client connection
! module, and the module in turn sends the commands to the rest of the
! daemon.
! \item For all the data received from the network that have service
! numbers registered by the client connetion module, the daemon makes a
! copy of the data and sends it to the module. Also, for all commands
! that returns some value, the daemon sends the resulting data to the
! client connection module.
! \item As it receives data from the rest of the daemon, the client
! connection module sends the data to the client (or the proper clients,
! if more than one client requested the same service or made the same
! command).
! \end{itemize}
! 
! \subsubsection{Commands}
! Here is a list of commands that can be sent downwards by a client
! connection module to the rest of the daemon.
! 
! \begin{description}
! \item[Register/Unregister service] Given some service number, it
! registers that service for its calling module instance. You can also
! unregister some service you don't want to use anymore. If you pass a
! flag saying ``all services'', then the service number given will be
! ignored and all possible service numbers will be registered or
! unregistered. If you register all services, all other calls to this
! command will be ignored except the next ``unregister all services''
! command.
! \item[Send packet] Sends an ANet packet, query[3] or static data[4],
! to the ANet network. The cluster group[5] where the packet will be
! sent has to be specified. Use the "Get Config" command (read below) to
! know which cluster groups you can use. The format of the "internal
! ANet packet" will be described in "Cluster Group Modules"[5].
! \item[Get Status] Will make the ANet daemon return a packet describing
! its current status. The contents of this packet will be implementation
! specific and outside the scope of the high-level design, though it
! will contain enough relevant information to let the user know what's
! going on in the daemon.
! \item[Get Status - Start/Stop polling] From the time the daemon gets
! the "Start Polling" command to the time it gets the "Stop Polling"
! command, the daemon will regularly send status packets the the client
! connection module. This is usefull for clients that want to monitor
! the status of the ANet daemon. With the "Start Polling" command, you
! can also specify what is the delay between when ANet will send the
! status packets, though if that value is too small, the command will be
! ignored.
! \item[Get Static Data] Given a primary and/or the secondary key, this
! will make ANet return all the static packets currectly stored locally
! that matches the key (or keys).
! \item[Change/Delete Static Data] Those commands will allow the module
! to change or delete some static packets currently stored locally.
! \item[Open TWDTC] Given the protocol, the ``unique address'' and the
! "subnet" of the other node, ANet will try to establish a Two-Way Data
! Transfer [3] Channel (TWDTC) to the other node through the network. If
! ANet didn't already find which node to use as a proxy (that can have
! access to the protocol and subnet you specified), it might take some
! time to establich the connection. Use the ``Get status'' commands to
! know what's going on.  ANet will return a packet containing an ID that
! can be used to identify the TWDTC with the other TWDTC commands.
! \item[Read/Write TWDTC] Read or write some data in the TWDTC. This is
! similar to reading or writing data in a TCP socket.
! \item[Close TWDTC] Given an open TWDTC ID\footnote{If you know what
! "TWDTC ID" means, then you're ready to be a developer for ANet!},
! closes the identified channel.
! \item[Get Config] Returns the readeable tags in the configuration
! files \xs{sec:rtw}. Each tag in the configuration files can have
! access rights, that is read, write or both. If specified, it affects
! the tag, and recursively overwriting the access rights of the tags it
! contain. Otherwise, they remain to their default value.
! \item[Change Config] Allows the client connection module to change
! tags in the configuration file, it it has the right to do so. The
! change can be saved to the hard disk, instead of being temporary, if
! the user has configured ANet to do so.
! \end{description}
  
+ \subsection{Implementation Notes}
+ There is no point of making one instance of the client connection
+ module per connection to a client. Most instances should be made
+ before having any connection to clients. Note that an instance cannot
+ "instantiate itself" as the daemon receives a connection: the instance
+ should exist to make whatever kind of connection it supports.  A
+ client connection module doesn't have to allow all the commands
+ allowed the the daemon. Actually, those modules can be very
+ sophisticated, for example gateways[7]
+ 
+ \subsection{DTD} 
+ See the complete DTD for more information.
+ 
+ \begin{figure}[!h]
+ \begin{fmpage}{\textwidth}
+ \begin{verbatim}
+ <!-- Client Connection Module -->
+ <!ELEMENT ClientConnection EMPTY>
+ <!ATTLIST ClientConnection %moduleName; %args; %security;>
+ \end{verbatim}
+ \end{fmpage}
+ \caption{The Client Connection Module DTD} \label{fig:ccmdtd}
+ \end{figure}
+ 
+ % References
+ 
+ % About the references...
+ 
+ % [1] Benad: "Run-Time Wrapper". Local link.
+ % [2] University of Southern California , "Internet Protocol". External link. Cached.
+ % [3] Benad: "Queries". Local link.
+ % [4] Benad: "Static Data". Local link.
+ % [5] Benad: "Gateways and Clusters". Local link.
+ % [6] Benad: "Anonymous Two-Way Data Transfers". Local link.
+ % [7] Benad: "Gateways and Clusters". Local link.
+ % [8] Apple: HyperCard. External link.
+ 
  \section{Data Transformation Modules} \label{sec:dtm}
  Transform some data.
***************
*** 343,356 ****
  \section{Document Type Definition (DTD)} \label{sec:dtd}
  This is the DTD file for the ANet configuration files.
- 
- \setcounter{chapter}{2}
- \part{Low-Level Design}
- %\chapter{Low-Level Design}
- \bibliographystyle{plain} \bibliography{anet}
  
  \appendix
  \appendixpage
  \addappheadtotoc
! \chapter{Graphs}
  \begin{figure}[!h]
  \begin{center}
--- 528,539 ----
  \section{Document Type Definition (DTD)} \label{sec:dtd}
  This is the DTD file for the ANet configuration files.
  
+ \clearpage
+ \pagenumbering{roman}
  \appendix
  \appendixpage
  \addappheadtotoc
! \section{Graphs}
! 
  \begin{figure}[!h]
  \begin{center}
***************
*** 360,363 ****
--- 543,551 ----
  \end{figure}
  
+ \clearpage
+ \bibliographystyle{plain} 
+ \bibliography{anet}
+ 
+ \clearpage
  \printindex
  \end{document}