X-Git-Url: http://git.rohieb.name/skm-ma-ws1314.git/blobdiff_plain/f1c1b4a2b8a9f899a42f91b362222b10f357a2c7..747e9d2a6f3468676b5e60d20e488e9a7891b06d:/xmpp.tex

diff --git a/xmpp.tex b/xmpp.tex
index b4dc98a..7bef910 100644
--- a/xmpp.tex
+++ b/xmpp.tex
@@ -25,15 +25,16 @@ the resource is only needed for routing between client and server.
   \centering
   \includegraphics[width=0.4\textwidth]{xmpp-architecture-mock.jpg}
   \caption{XMPP architecture}
+  \label{fig:xmpparch}
 %\end{figure}
 \end{wrapfigure}
 
 The original architecture underlying XMPP strongly leans on the established
-design of Internet Mail. The distributed network is formed by \term{XMPP
-servers} on one hand, which make up the always available backbone of the network
-and manage user accounts and statuses, and \term{XMPP clients} on the other
-hand, which represent a single logged-in user and make up the interface for
-communication with other users.
+design of Internet Mail, and an example is depicted in Fig.~\ref{fig:xmpparch}.
+The distributed network is formed by \term{XMPP servers} on one hand, which make
+up the always-on backbone of the network used for routing message, and manage
+user accounts and statuses. On the other hand, \term{XMPP clients} represent a
+single logged-in user and are the interface for communication with other users.
 
 Every client communicates only with the server that manages the respective user
 account which is configured in the client, as given in the user's JID. The
@@ -43,37 +44,78 @@ sends the message to a client where the receiving JID is logged in. If the user
 is not logged in at the time the message is sent, the server can store it for
 the user and deliver it on the next login.
 
-\todo{use of DNS-SD?}
+XMPP strongly relies on DNS Service Discovery (see Section~\ref{sec:dnssd}) to
+determine the server being in charge of a domain. For example, the server who
+manages the users for the domain \code{example.org} is given by the SRV record
+\code{\_xmpp-server.\_tcp.example.org}.
 
 \subsubsection{Communication primitives}
 
+All communication over XMPP is based on XML. To minimize communication overhead,
+only fragments of XML, called \term{stanzas}, are sent between hosts. A stanza
+is always well-formed as a whole; it consist of a root element, which also
+includes routing attributes (\code{to} and \code{from}), and its optional child
+elements.
+
+On top of that, living connections between hosts are represented by \term{XML
+streams}. The client initiates a connection by sending an XML declaration
+followed by an opening \code{<stream>} tag. The server then responds also with
+an opening \code{<stream>} tag. The client then performs SASL authentication and
+binds its stream to a resource for proper addressing. If this process succeeded,
+both client and server can send an unlimited number of stanzas, until the
+connection is closed by one side by sending an closing \code{</stream>} tag. The
+other side then has the chance to send all outstanding stanzas and likewise
+closes its stream. If both streams are closed, the underlying TCP connection is
+terminated.
+
+\todo[Example stream]
+
 \subsubsection{Multi-User Chats}
 
 \cite{xep-0045}
 
-\subsubsection{Publish/Subscribe and the Roster}
-
-is this really needed?
+\subsubsection{Publish/Subscribe, Presence and the Roster}
 
 \cite{xep-0060}
 
-\subsubsection{Presence}
 
+\cite{rfc6121}
+
+\subsubsection{XMPP Serverless Messaging}
+\todo
+
+To overcome the need for a central server and authentication, XMPP Serverless
+Messaging~\cite{xep-0174} allows XMPP clients on a network to build a
+peer-to-peer mesh network and chat directly with each other. This feature was
+first introduced by Apple as part of their \term{Bonjour} project, and nowadays
+it is also available in many other XMPP clients.
+
+With XMPP Serverless Messaging, XMPP clients simply open a port on the host, and
+then rely on mDNS and DNS-SD (see Section~\ref{sec:dns})
+to publish instance names in the domain \code{\_presence.\_tcp.local}. For
+example, if Juliet uses her machine (named \code{capulet}) with serverless
+messaging, her client would publish the following four mDNS records:
 
-\cite{rfc6120}
 \begin{itemize}
-	\item architecture: client-server, use of DNS-SD
-	\item addressing: JIDs, resources
-	\item XML-based communication primitives, stanzas and streams
-	\item presence
-	\item publish/subscribe \cite{xep-0060}, roster
-	\item multi-user chats \cite{xep-0045}
+  \item an A record \code{capulet.local}, specifying her IP address,
+  \item an SRV record \code{juliet@capulet.\_presence.\_tcp.local}, specifying
+    the port on which her XMPP client listens, and refering to
+    \code{capulet.local} as the host name
+  \item a PTR record \code{\_presence.\_tcp.local} for service discovery,
+    pointing to \code{juliet@capulet.\_presence.\_tcp.local}
+  \item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying
+    more information about her (e.~g. her online status, contact data, etc.)
 \end{itemize}
 
+When other clients in the same network enumerate the available services by
+querying \code{\_presence.\_tcp.local}, they notice Juliet's presence and add
+her to the roster automatically. In that way, XMPP users can see who is
+currently available for communication. To start a chat session, clients initiate
+a TCP connection over the advertised ports, open their XML streams, and send
+message or IQ stanzas like they would to an XMPP server. Presence is managed
+over the corresponding TXT record in the mDNS. To go offline, a client
+announces the deletion of its mDNS records.
 
-
-\subsubsection{XMPP Serverless Messaging}
-\todo
-\cite{xep-0174} \pages{1}
+\pages{1}
 
 % vim: set ft=tex et ts=2 sw=2 :
