\usepackage[utf8x]{inputenc}
\usepackage[ps2pdf]{hyperref}
\usepackage{reqlist}
+\usepackage{longtable}
-\newcommand{\urlink}[1]{\texttt{<#1>}}
+\newcommand{\urlink}[1]{\texttt{<\url{#1}>}}
\newcommand{\unix}{\textsc{Unix}}
\title{Dolda Connect protocol}
\maketitle
+\tableofcontents
+
\section{Introduction}
Dolda Connect consists partly of a daemon (a.k.a. server) that runs in
the background and carries out all the actual work, and a number of
their own client programs.
It is worthy of note that there exists a library, called
-\texttt{libdcui} that carries out much of the low level work of
+\texttt{libdcui}, that carries out much of the low level work of
speaking the protocol, facilitating the creation of new client
programs. In itself, \texttt{libdcui} is written in the C programming
language and is intended to be used by other programs written in C,
project's Scheme interpreter) and for Python. The former is
distributed with the main Dolda Connect source tree, while the latter
is distributed separately (for technical reasons). To get a copy,
-please refer to Dolda Connect's homepage at
-\urlink{http://www.dolda2000.com}.
+please refer to Dolda Connect's homepage:
+
+\urlink{http://www.dolda2000.com/~fredrik/doldaconnect/}
\section{Transport format}
Note: Everything covered in this section is handled by the
Formally, the syntax of the protocol may be defined with the following
BNF rules. Note that they all operate on Unicode characters, not bytes.
-\begin{tabular}{lcl}
+\begin{longtable}{lcl}
<session> & ::= & <SYN> <response> \\
& & | <session> <transaction> \\
& & | <session> <notification> \\
& & | ``\texttt{5}'' | ``\texttt{6}'' |
``\texttt{7}'' | ``\texttt{8}'' |
``\texttt{9}''
-\end{tabular}
+\end{longtable}
As for the terminal symbols, <SPACE> is U+0020, <TAB> is U+0009,
<CRLF> is the sequence of U+000D and U+000A, <DASH> is U+002D, <CHAR>
if a request with any other non-existing command were sent. Any
remaining words on the line are considered arguments to the command.
+\section{Data model}
+
+The main purpose of the protocol is to communicate the current state
+of the daemon to the client and keep it synchronized. Therefore, in
+order to understand the actions of the individual requests, an
+understanding of the data structures that define the current state is
+fundamental. The intent of this section is document those structures
+in a top-down approach.
+
+\subsection{Filesharing network}
+\label{fnet}
+At the heart of the Dolda Connect daemon lies the abstraction of a
+file sharing network, often abbreviated ``filenet'' or ``fnet''. To
+the daemon, a filenet is a software module that speaks a certain
+filesharing protocol, such as the Direct Connect protocol. A client
+program will never interact directly with any filenet module, but it
+is often important to know that there are several filenet
+modules\footnote{Actually, at the time of this writing, that is false,
+ as only the Direct Connect protocol is implemented. However, the
+ protocol still requires it explicitly stated at several occasions,
+ and it is nonetheless important to keep in mind that there
+ \emph{could} be several filenet modules. Also, work is under way to
+ implement ADC, the ``official'' successor to the Direct Connect
+ protocol.}. The only detail visible to clients about a filenet is
+its name. The currently implemented filenet modules are listed in
+section \ref{fnets}, along with important information about each.
+
+\subsection{Filenet node}
+\label{fnetnode}
+The filenet node, often abbreviated ``fnetnode'', corresponds closely
+to the Direct Connect concept of a ``hub''.
+
\section{Requests}
+
For each arriving request, the daemon checks so that the request
passes a number of tests before carrying it out. First, it matches the
name of the command against the list of known commands to see if the
\input{commands}
+\section{Filesharing networks}
+\label{fnets}
+
\end{document}
Dolda2000 GitWeb / doldaconnect.git / blobdiff