\usepackage[T1]{fontenc}
\usepackage[utf8x]{inputenc}
+\usepackage[ps2pdf]{hyperref}
\usepackage{reqlist}
+\usepackage{longtable}
-\newcommand{\url}[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
-\url{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
\end{table}
\subsection{Protocol revisions}
-
+\label{rev}
Since Dolda Connect is developing, its command set may change
occasionally. Sometimes new commands are added, sometimes commands
change argument syntax, and sometimes commands are removed. In order
certain revision and be sure that everything it wants is supported by
the daemon.
+At the time of this writing, the latest protocol revision is 2. Please
+see the file \texttt{doc/protorev} that comes with the Dolda Connect
+source tree for a full list of revisions and what changed between
+them.
+
\subsection{List of commands}
Follows does a (hopefully) exhaustive listing of all commands valid
for a request. For each possible request, it includes the name of the
-command for the request, the permissions required, the syntax the
+command for the request, the permissions required, the syntax for the
entire request line, and the possible responses.
The syntax of the request and response lines is described in a format
has no command name and no syntax, but needs a description
nonetheless.
+\revision{1}
+
\noperm
\begin{responses}
The old response given by daemons not yet using the revisioned
protocol. Clients receiving this response should consider it an
error.
+ \response{201 LOREV HIREV}
+ Indicates that the connection is accepted. The \param{LOREV} and
+ \param{HIREV} parameters specify the range of supported protocol
+ revisions, as described in section \ref{rev}.
+ \response{502 REASON}
+ The connection is refused by the daemon and will be closed. The
+ \param{REASON} parameter states the reason for the refusal in
+ English\footnote{So it is probably not suitable for localized
+ programs}.
\end{responses}
+\input{commands}
+
+\section{Filesharing networks}
+\label{fnets}
+
\end{document}
Dolda2000 GitWeb / doldaconnect.git / blobdiff