summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorSebastien Braun2010-11-05 00:57:04 +0100
committerSebastien Braun2010-11-05 00:57:04 +0100
commitfc815ad2b711f0205801ddb04f85c9c776183efd (patch)
treec5a8213fe9caf8a7311a02642953a7041484fda3 /doc
parentDoxygen configuration for pvsinput. (diff)
downloadpvs-fc815ad2b711f0205801ddb04f85c9c776183efd.tar.gz
pvs-fc815ad2b711f0205801ddb04f85c9c776183efd.tar.xz
pvs-fc815ad2b711f0205801ddb04f85c9c776183efd.zip
Remove accidentally added backup files
Diffstat (limited to 'doc')
-rw-r--r--doc/LaTeX/devel/0100-build.tex~69
-rw-r--r--doc/LaTeX/devel/0300-pvs.tex~384
2 files changed, 0 insertions, 453 deletions
diff --git a/doc/LaTeX/devel/0100-build.tex~ b/doc/LaTeX/devel/0100-build.tex~
deleted file mode 100644
index 66d94da..0000000
--- a/doc/LaTeX/devel/0100-build.tex~
+++ /dev/null
@@ -1,69 +0,0 @@
-\chapter{Erzeugen und Installieren der Applikation}
-\index{Installieren}
-Um den Pool Video Switch erfolgreich zu kompilieren, müssen zunächst die Quelldateien heruntergeladen werden. Hierzu sollte auf dem Arbeitsrechner ein Subversion-Client installiert sein. Ein Checkout kann in einem beliebigen Terminal erfolgen, wobei es zwei unterschiedliche Arten des Zugriffs gibt.\\
-
-Anonym, nur Leserechte:\\
-\textbf{svn co http://svn.openslx.org/svn/pvs/trunk/pvs}\\
-
-Mit Account, auch Schreibrechte (benutzer mit SSH Login ersetzen):\\
-\textbf{svn co svn+ssh://benutzer@openslx.org/srv/svn/pvs}\\
-
-
-\section{Voraussetzungen}
-Der Pool Video Switch benötigt zum Kompilieren folgende Pakete (und ihre Abhängigkeiten):
-\begin{itemize}
- \item libvncserver-dev >= 0.9.3\\
- Eine angenehm kleine, wenn auch in C geschriebene, Bibliothek für die Erstellung von VNC Servern und Clients.
- \item libx11-dev >= 1.3.3\\
- Diese Bibliothek wurde eingesetzt, um ausgewählten oder allen Zielrechnern den Zugriff auf Maus und Tastatur zu entziehen und den Bildschirm schwarz zu schalten.
- \item libqt4-dev >= 4.5.3\\
- Sowohl die Server als auch die ClientGUI benutzen das Qt Framework in der Version 4. Ferner wird QtNetwork zur Kommunikation zwischen Server und Client benötigt und QtDbus zur Interprozesskommunikation zwischen Client-Daemon und GUI.
- \item qt4-dev-tools >= 4.5.3\\
- Dies wird nur benötigt, falls Unterstützung weiterer Sprachen implementiert werden soll, da in diesem Paket das Hilfsprogramm \textbf{linguist} enthalten ist.
- \item cmake >= 2.4.0\\
- Eingesetztes Buildsystem und der Makefile-Generator. Um distributionsspezifische Pakete zu erzeugen wird CPack benutzt.
- \item libxtst-dev, libxi-dev\\
- Diese Bibliotheken dienen zur Implementierung der Fernsteuerungsfunktionen.
-\end{itemize}
-
-\section{Kompilieren aus Quellen}
-Sobald alle Voraussetzungen erfüllt und die Quellen installiert sind, kann das ausführbare Programm erzeugt werden. Falls gewünscht, kann zusätzlich in der Datei \textit{CMakeLists.txt} der Build-Type eingestellt werden. Gültige Werte sind \texttt{Debug} und \texttt{Release} und ihre Wirkung den zwei weiteren Zeilen zu entnehmen.
-\begin{verbatim}
-SET(CMAKE_BUILD_TYPE Debug)
-SET(CMAKE_CXX_FLAGS_DEBUG "-O0 -g -Wall")
-SET(CMAKE_CXX_FLAGS_RELEASE "-O3 -march=native")
-\end{verbatim}
-Damit das Wurzelverzeichnis des Projekts weiterhin sauber bleibt (Übersicht beibehalten, Arbeit mit SVN erleichtern), werden wir hier einen Out-Of-Source Build durchführen. Dies bedeutet, dass zum Kompilieren ein seperates Verzeichnis benutzt wird und sämtliche automatisch generierten Dateien sowie das Kompilat selbst hier abgelegt wird. In einem Terminal sollte nun in das Verzeichnis indem sich das Projekt befindet gewechselt werden, um folgende Befehle ausführen zu können:\\
-
-\textbf{mkdir -p build}\\
-\textbf{cd build/}\\
-\textbf{cmake ..}\\
-\textbf{make}\\
-
-Die verschiedenen Applikationen können nun folgendermaßen (in \textit{build/}) ausgeführt und getestet werden:
-\begin{itemize}
- \item Den Server starten: \textbf{./pvsmgr}
- \item Den Server mit Touchscreenoberfläche starten: \textbf{./pvsmgrtouch}
- \item Den ClientDaemon starten: \textbf{./pvs}
- \item Die ClientGUI starten: \textbf{./pvsgui}
-\end{itemize}
-
-\section{Installation}
-\index{Paket!RPM} \index{Paket!DPKG}
-Nachdem das Projekt kompiliert wurde, kann es (als Superuser z.B. root) auf dem lokalen System installiert werden:\\
-\textbf{make install}\\
-
-Dabei werden folgende Dateien auf das aktuelle System übertragen:\\
-\textit{/usr/local/bin/pvsmgr}\\
-\textit{/usr/local/bin/pvs}\\
-\textit{/usr/local/bin/pvsgui}\\
-\textit{/usr/local/bin/pvsmgrtouch}\\
-\textit{/usr/local/share/dbus-1/services/org.openslx.pvs.service}\\
-
-Ein Vorteil ist, dass nun ein seperates Ausführen des Client-Daemon nicht mehr notwendig ist. Dieser wird ab sofort automatisch gestartet und beendet, sobald die ClientGUI ausgeführt wurde.\\
-
-Es ist ebenfalls möglich, distributionsspezifische Pakete zu erstellen (zur Zeit nur .deb):\\
-\textbf{make package}\\
-
-Falls erfolgreich, befindet sich nun eine Installationsdatei (pvs-<version>-Linux.deb) in \textit{build/} die z.B. auf Debian-Derivaten mit \textbf{dpkg -i} installiert werden kann.\\
-Anmerkung: Falls Pakete für Rechner gebaut werden sollen, die vom Erstellungssystem her verschieden sind, muß der Schalter \texttt{-march=native} in der Datei \textit{CMakeLists.txt} angepasst werden!
diff --git a/doc/LaTeX/devel/0300-pvs.tex~ b/doc/LaTeX/devel/0300-pvs.tex~
deleted file mode 100644
index ac88e46..0000000
--- a/doc/LaTeX/devel/0300-pvs.tex~
+++ /dev/null
@@ -1,384 +0,0 @@
-\chapter{Aufbau und Funktionsweise des PVS}
-\index{Aufbau} \index{Funktionsweise} \index{Konzept}
-
-Generelles Konzept
-
-\section{Einzelne Komponenten}
-\index{Komponenten}
-
-\subsection{Zuordnung von Konsole und Clients}
-\input{devel/0310-service-discovery}
-
-\section{Überblick über Aktivitäten auf Clients}
-
-\subsection{Projektion an Alle}
-\index{Projektion}
-Eine wichtige Eigenschaft des PVS ist die Verwaltung von Projektionen zwischen mehreren Clients. Eine Projektion ist hierbei das Anzeigen des Bildschirminhalts eines Clients - der sogenannten Source oder Quelle - auf einem oder mehreren anderen Clients - den Targets oder Zielen der Projektion.
-Die für die Projektion benötigten Verbindungsdaten wie Passwort und IP werden von jedem Client bei der Anmeldung an der Steuerkonsole übermittelt und in einer Liste von PVSConnection Objekten in der Klasse \textit{PVSConnectionManager} gespeichert. Diese zentrale Verwaltung hat mehrere Vorteile:
-\begin{itemize}
- \item Die Quelle einer Projektion muss keine Aktion ausführen und kann passiv bleiben.
- \item Redundanz der Daten wird verhindert, da diese auch in der Steuerkonsole zur Darstellung der Thumbnails benötigt werden.
- \item Das Nachrichtenaufkommen wird reduziert, da lediglich eine Nachricht bei der Anmeldung an der Steuerkonsole übermittelt wird.
-\end{itemize}
-
-Bei der Auswahl der Quelle und Ziele ist zu beachten, dass man für jede Projektion jeweils nur eine Quelle jedoch mehrere Ziele auswählen kann.
-Quelle und Ziel müssen außerdem verschiedenen Kriterien genügen.
-\begin{itemize}
- \item Eine Quelle darf nicht gleichzeitig Ziel einer Projektion sein.
- \item Ein Ziel einer Projektion darf nicht Ziel einer anderen Projektion sein.
- \item Eine Quelle darf mehrfach als Quelle ausgewählt werden.
-\end{itemize}
-Diese Einschränkungen werden in der Steuerkonsole durchgesetzt, indem im Zielauswahldialog die Zielmenge eingeschränkt wird.
-Siehe hierzu auch \ref{pvs-console-projection} Projektion.
-
-Der Projektionsvorgang an sich besteht aus mehreren Teilen. Wird eine Projektion angefordert, wird überprüft, ob auf der Quelle ein VNC Server gestartet ist. Falls nicht, wird versucht, einen VNC Server zu starten. Ist dies erfolgreich, so sendet die Steuerkonsole das entsprechende Tripel (IP, Passwort und Port der Quelle) an alle ausgewählten Ziele. Clients, welche eine Projektionsaufforderung erhalten, verbinden sich dann mit den Verbindungsdaten zum VNC Server der Quelle. Um die Einstellbarkeit der Qualität einer Projektion zu ermöglichen, kann die Steuerkonsole einen von drei Qualitätswerten an die Zielclients übermitteln. Siehe hierzu auch \ref{pvs-console-quality} Qualitätsoptionen.
-
-
-\subsection{Projektion eines Clients auf dem Beamer}
-\index{Beamer}
-
-Die Projektion eines Clients an den Beamer unterscheidet sich im Wesentlichen nicht von anderen Projektionen. Lediglich ist das Ziel der Projektion hierbei der Dozentenpc bzw. der PC, welcher an den Beamer angeschlossen ist. Eine spezielle Auszeichnung des Beamers erfolgt nicht. Die Anzahl der Ziele wird hierbei nicht beschränkt, da es wünschenswert sein kann, den auf dem Beamer dargestellten Bildschirminhalt auch gleichzeitig auf anderen Clients darzustellen.
-
-\subsection{Chat- und Informationskanal}
-\index{Chat}
-
-Es gibt 2 Möglichkeiten um Kontakt mit den Clients aufzunehmen. Die erste ist über den Chat, wo Nachrichten sowohl über den offentlichen Kanal als
-auch über einen privaten Kanäle verteilt werden können, und die zweite vom PVSManager aus über den Informationskanal.
-Der Informationskanal ermöglich das Versenden von Nachrichten, die dringend zu lesen sind, an die Clients.
-Im Gegenteil zum Chat erscheinen solche Nachrichten nicht im Chatfenster sondern in einem Pop-Up-Fenster und werden vom Bildschirm entfernt erst wenn man sie
-als gelesen markiert durch das Drucken auf dem Knopf \textit{'OK'}.
-\\
-\\
-\textbf{Behandlung der Nachrichten im Server}
-\\
-\\
-Chat-Nachtichten werden von Server in der Klasse \texttt{PVSConnectionManager} mittels der Methode \texttt{onChat} behandelt. Dort wird aus der Nachrit den Empfänger
-und den Absender ausglesen und die Nachricht an beide versendet. So gilt das Empfangen eine eigene Nachricht als Bestätigung, dass die Nachricht ordentlich vom Server
-behandelt und versendet wurde. Das Gestalt von solchen Nachrichten sieht folgendermaßen aus
-
-\begin{center}
- PVSMSG
-\end{center}
-\begin{center}
-\begin{tabular}{|l | p{3cm} | p{3cm} | p{3cm}|}
-\hline
-Type & Ident & Msg & sndID\\
-\hline
-\texttt{PVSMESSAGE} & \texttt{<Username des Empfängers>} & \texttt{<<Username des Absenders>:<Die eigentliche nachrich>} & \texttt{<<Vom server zugewissene ID des Absenders>}\\
-\end{tabular}
-\end{center}
-
-Informationsnachrichten werden ausschließlich vom PVSManager versendet.Dies geschiet in der Klasse \texttt{ConnectionList} mittels der Methode \texttt{on\_Message}.
-
-\begin{center}
- PVSMSG
-\end{center}
-\begin{center}
-\begin{tabular}{|l | l | p{6cm} | p{6cm}}
-\hline
-Type & Ident & Msg\\
-\hline
-\texttt{PVSMESSAGE} & \texttt{BROADCAST} & \texttt{<Die eigentliche nachrich>} \\
-\end{tabular}
-\end{center}
-
-Informationnachrichten können außerdem einen oder mehrere Clients sperren, wenn sie den Ident \texttt{LOCKSTATION} enthalten. Sobald ein Client die Nachricht empfängt,
-wird diese auf dem Bilschirm angezeigt und 10 Sekunden später wird der Client gesperrt.
-
-Abgesehen von der Behandlung der Nachrichten muss sich der Server darum kümmern, dass jeder verbunde Client über alle nötige Informationionen verfügt damit er
-Nachrichten mit andren Clients austauschen kann. Dies wird folgendermaßen erledigt:
-\begin{itemize}
- \item \textbf{Einfügen eines Clients:} um die Verwaltung von Clients kümmert sich die Klasse \texttt{PVSConnectionManager}, in der die Methode \texttt{onClientNew} für das Einfügen
-von neuen Clients zuständigt ist. Sowald ein neuer Client in der Client-Liste des Servers eingefügt wird, wird an ihn die Liste aller im Server bereits angemeldete
-Clients geschickt. Dazu dient die Methode \texttt{sendEventToClients}.
-
-Bis hier ist der neue Client noch unbekannt für den Rest der Nutzer. Der neuer Client wird erst bekannt gegeben sobald er vom Server einen Benutzername
-zugewissen bekommen hat. Da es sein kann, dass den Name, mit dem der neue Client sich beim Server anmelden wollte,
-bereits vergeben ist und muss unter Umständen verändert werden. Diese Zuweisung findet in der Methode \texttt{onLoginUsername} statt,
-wo nicht nur alle andere Clients sondern auch der neue Client darüber informiert werden. Auch hier kümmert sich die Methoder \texttt{sendEventToClients}
-ums Vesenden der entsprechenden Informationen.
-
- \item \textbf{Entfernen eines Clients:} das Entfernen von Clients wird von der Methode
-\\
-\texttt{onClientRemove} erledigt, wo analog wie
-Oben alle Clients darüber informiert werden.
-\end{itemize}
-
-Für dei Übermittlung solche Informationen werden Nachrichten mit folgenden Gestal benutzt
-
-\begin{center}
- PVSMSG
-\end{center}
-\begin{center}
-\begin{tabular}{|l | l | p{6cm} |}
-\hline
-Type & Ident & Msg\\
-\hline
-\texttt{PVSMESSAGE} & \texttt{<Befehl>} & \texttt{<Benutzername>:<IP-Adresse>} \\
-\end{tabular}
-\end{center}
-
-Es gibt drei unterschiedliche Befehle, die welche Änderung in der localen Client-Liste der Clients vorgenommen werden soll angeben.
-\begin{enumerate}
- \item \texttt{clientToAdd}
-\item \texttt{clientToRemove}
-\item \texttt{assignedName}
-\end{enumerate}
-
-Wie es bei Servern gewöhnt ist, werden alle relevante Ereignisse in Log-Dateien protokolliert. Ereignisse werden im Chat-Log mit folgendem
-Befehl eingetragen
-
-\begin{center}
-\texttt{ConsoleLog writeChat(<Beschreibung des Ereignisses>)}
-\end{center}
-
-\textbf{Chat-Interface der Steuerkonsole}
-\\
-\\
-So wie alle Clients ist der PVSManager auch ein Teilnehmer im Chat. Der PVSManager steht wie alle andere Teilnehmer auch in der Nutzer-Liste
-jedes Chat-Fenster und kann ebenfalls über private Nachrichten direkt angesprochen werden. Die Arbeitsweise dieser Chat-Interface ist sehr simple.
-Da sie sich im Server befindet, müssen einfach alle Ereignise (Nachrichten senden ist die einzige Ausnahme) von der Klasse \texttt{PVSConnectionManager}
-an die Klasse \texttt{MainWindow} weitergegeben werden. Dies kümmert sich darum, alle Informationen zu verarbeiten und diesein der Chat-Fenster der
-Steuerkonsole anzuzeigen.
-
-Folgende Methoden der Klasse \texttt{MainWindow} ermöglichen das Anzeigen einer empfangenen Nachricht im Chat-Fenster der Steuerkonsole und Änderungen (Clients einfügen
-und entfernen) in der sowohl im Chat-Fenster als auch in der Steuerkonsole angezeigten Client-Liste.
-\\
-\\
-\texttt{receiveChatMsg(<Absender>, <Empfänger>, <Nachricht>)}
-\\
-\texttt{removeConnection(*pvsClient)}
-\\
-\texttt{addConnection(*pvsClient)}
-\\
-\\
-Alle diese Methoden werden im Gegensatz von der Methode \texttt{sendChatMsg(PVSMsg myMsg)} von der Klasse \texttt{PVSConnectionManager} aus ausgeführt. Da alle durchs
-Netz empfangene Nachrichten müssen an die GUI-Weitergegeben werden. Beim Versenden von Nachrichten funktioniert es genau umgekehrt. Die Nachricht wird
-vom Nutzer in der GUI eingegeben und muss an die Klasse \texttt{PVSConnectionManager} weitergeleitet werden, damit diese ins Netz gesendet wird. Darum kümmert
-sich die Methode in der Klasse \texttt{MainWindow}.
-\\
-\\
-\texttt{MainWindow::sendChatMsg(PVSMsg myMsg)}
-\\
-\\
-\textbf{Chat-Clients}
-\\
-\\
-So weit haben wir die Funtionsweisen des Servers im Bezug auf dem Chat kennengelernt.
-Nun wird erläutert wie die einzelnen Clients die Nachrichten bearbeiten.
-\\
-\\
-Auf der Client-Seite in der Klasse \texttt{PVSConnectionServer} werden alle Nachrichten des PVS-Protokolls empfangen und gefiltert (Siehe Methode \texttt{handleClientMsg}).
-Nachrichten mit dem Ident \texttt{PVSMESSAGE} werden durch den Dispatcher direkt an die Klasse \texttt{PVSChatClient} weitergeleitet, wo die Methode \texttt{receive} feststellen wird,
-ob es sich dabei um eine Gespräch-Nachricht oder eine Befehl-Nachricht handelt. Um es feststellen zu können, wird aus der empfangenen Nachricht ein PVSChatMsg-Objekt
-erzeugt (siehe Konstruktor) und mittels der Methode \texttt{isCommand} erfährt man ob es sich um einen Befehl handelt oder nicht.
-Falls ja leitet der Dispatche die Nachricht an die Stelle \texttt{PVS::UpdateChatClients} sonst an die Stelle \texttt{PVS::chat\_receive}, wo die Änderungen in der Client-Liste
-vorgenommen werden oder die Gespräch-Nachricht der GUI abgegeben wird.
-
-\section{Fernsteuerung}
-
-Die Fernsteuerung eines Clients erfolgt durch den clientseitigen Empfang von \texttt{PVSCOMMAND}-Nachrichten
-mit dem Ident \texttt{INPUTEVENT}.
-Dieser ist die Base64-kodierte Binärdarstellung eines Eingabeereignisses angehängt, das
-clientseitig nachvollzogen werden soll.
-\begin{table}
- \begin{tabular}{|l|l|p{4cm}|p{4cm}|}
- \hline
- \textbf{\texttt{type}} & \textbf{\texttt{code}} & \textbf{\texttt{value}} & \textbf{Beschreibung} \\
- \hline
- \multirow{2}{*}{\texttt{ET\_KEY}} &
- \texttt{EC\_PRESS} &
- \multirow{2}{4cm}{Auslösende Taste und gehaltene Modifikatortasten} &
- Taste gedrückt \\
- \cline{2-2}\cline{4-4}
- &
- \texttt{EC\_RELEASE} &
- &
- Taste losgelassen\newline \\
- \hline
- \multirow{2}{*}{\texttt{ET\_BUTTON}} &
- \texttt{EC\_PRESS} &
- \multirow{2}{4cm}{Auslösende und
- gedrückte Maustasten} &
- Maustaste gedrückt \\
- \cline{2-2}\cline{4-4}
- &
- \texttt{EC\_RELEASE} &
- &
- Maustaste losgelassen \\
- \hline
- \texttt{ET\_POINTER} &
- --- &
- Absolute Koordinaten &
- Mauszeiger bewegt \\
- \hline
- \multirow{4}{*}{\texttt{ET\_SPECIAL}} &
- \texttt{EC\_REBOOT} &
- --- &
- Systemneustart \\
- \cline{2-4}
- &
- \texttt{EC\_KILL\_X} &
- --- &
- X-Server töten \\
- \cline{2-4}
- &
- \texttt{EC\_SYSRQ} &
- Kommando &
- Magic-SysRq-Taste \\
- \cline{2-4}
- &
- \texttt{EC\_SAY\_HELLO} &
- --- &
- Harmloses Kommando für Funktionstest \\
- \hline
- \end{tabular}
- \caption{Mögliche Eingabeereignisse\label{tab:input-events}\index{Eingabeereignis!\texttt{InputEvent}}}
-\end{table}
-Tabelle \ref{tab:input-events} zeigt die möglichen Eingabeereignisse.
-Eingabeereignisse werden durch die PVS Input Library (libpvsinput) behandelt,
-deren Funktion an dieser Stelle dargestellt werden soll.
-
-\subsection{Behandlung eines Eingabeereignisses}
-\index{Eingabeereignis!Behandlung}
-
-Ein Eingabeereignis durchläuft die folgenden Stationen:
-\begin{enumerate}
- \item Die Steuerkonsole generiert ein Eingabeereignis und übergibt dieses an die Netzwerktransportschicht.
- \item Der PVS-Client empfängt das Eingabeereignis und übergibt die Behandlung einer Instanz der
- Klasse \texttt{InputEventHandlerChain}\index{Klasse!\texttt{InputEventHandlerChain}}.
- \item Die Klasse \texttt{InputEventHandlerChain} arbeitet eine Liste von Instanzen der Klasse
- \texttt{InputEventHandler}\index{Klasse!\texttt{InputEventHandler}} der Reihe nach ab, um zu sehen, ob eine dieser Instanzen
- das Ereignis bearbeiten kann.
- \item Falls die betrachtete Instanz das Ereignis bearbeiten kann, wird geprüft, ob der dafür
- nötige Sicherheitskontext vorhanden ist.
- \item Falls dies ebenfalls der Fall ist, wird die entsprechende Aktion in einer implementierung
- der abstrakten Methode \texttt{InputEventHandler::handle} ausgeführt und die weitere Bearbeitung
- beendet.
- \item Falls keiner der vorherigen Handler das Ereignis behandelt hat, wird es durch
- die Klasse \texttt{PrivilegedHandlerForwarder}\index{Klasse!\texttt{PrivilegedHandlerForwarder}} an den zusätzlichen Daemon \texttt{pvsprivinputd}
- weitergegeben.
- \item Der \texttt{pvsprivinputd}\index{pvsprivinputd} besitzt ebenfalls eine \texttt{InputEventHandlerChain}, die
- nach dem gleichen Muster bearbeitet wird.
- Falls hierbei kein passender Handler gefunden wird, wird das Ereignis in eine Logdatei geschrieben
- und die Bearbeitung aufgegeben.
-\end{enumerate}
-Ereignishandler sind implementiert für Maus- und Tastatureingaben unter Linux/X11 (mit Hilfe der XTest-Erweiterung),
-sowie zur Simulation von Strg+Alt+Entf, Strg+Alt+Rück und Magic SysRq.
-
-\subsection{Erweiterungen}
-
-Weitere Eingabehandler lassen sich der libpvsinput hinzufügen.
-Dazu muss eine Klasse bereitgestellt werden, die von der Template-Klasse
-\texttt{InputEventHandler} erbt.
-Diese akzeptiert eine variable Anzahl\footnote{%
- Bis zu 16, diese Zahl lässt sich jedoch durch Neugenerierung
- der Datei \texttt{src/input/detail/ typelist\_autogen.h} erhöhen.
- Ein entsprechendes Programm ist im Quellcode zu finden.}
-von Templateparametern, die verschiedene Aspekte der Eingabeereignisbehandlung konfigurieren.
-
-Durch die Angabe eines Templateparameters \texttt{input\_policy::Match<\textit{typ}, \textit{code}, \textit{wert}>}\index{Klasse!\texttt{input\_policy::Match}},
-wobei \textit{code} und \textit{wert} weggelassen werden können, wird spezifiziert,
-dass der betreffende Handler nur für Eingabeereignisse mit den entsprechenden Feldwerten aufgerufen wird.
-Wird kein solcher Parameter angegeben, wird der betreffende Handler niemals aufgerufen.
-Mehrere \texttt{Match}-Parameter werden mittels logischem ODER verknüpft.
-
-Ein Templateparameter der Form \texttt{input\_policy::Require<\textit{Merkmal\dots}>}\index{Klasse!\texttt{input\_policy::Require}}
-gibt an, dass dieser Handler nur auf einem System lauffähig ist, das die entsprechenden \textit{Merkmale}
-aufweist.
-Eine Liste von Systemmerkmalen wird in der Datei \texttt{src/input/detail/systemTraits.h}
-zentral verwaltet.
-Hier lassen sich neue Merkmale mit Hilfe des Makros \texttt{DEFINE\_SYSTEM\_TRAIT} definieren
-und mit Hilfe des Präprozessors zwischen den Zeilen \texttt{BEGIN\_SYSTEM\_TRAITS} und
-\texttt{END\_SYSTEM\_TRAITS} einfügen.
-Diese Vorgehensweise beschränkt die Nutzung des Präprozessors auf eine Datei.
-Wird kein \texttt{Require}-Parameter angegeben, so wird der entsprechende Handler als
-immer lauffähig eingestuft.
-Mehrere \texttt{Require}-Parameter werden mittels logischem ODER verknüpft.
-
-Weiterhin kann ein Templateparameter der Form \texttt{input\_policy::Security<\textit{Richtlinie}>}\index{Klasse!\texttt{input\_policy::Security}}
-angegeben werden. Hierbei stehen für \textit{Richtlinie} die Klassen \texttt{input\_policy::AllowLocal\-OrPrivileged}
-oder \texttt{input\_policy::AllowEverybody} zur Verfügung.
-Hierdurch wird bestimmt, welche Sicherheitsanforderungen zur Ausführung des Handlers erfüllt sein
-müssen.
-Die Richtlinie \texttt{input\_policy::AllowLocalOrPrivileged} bestimmt, dass nur Benutzer,
-deren Sitzung lokal ist, oder solche, die nach der Konfiguration des pvsprivinputd als privilegiert
-gelten, die entsprechende Aktion aufrufen dürfen (hierbei geht es um den Benutzer, der den PVS-Client
-ausführt, und nicht den Benutzer, der die Steuerkonsole bedient).
-Die Richtlinie \texttt{input\_policy::AllowEverybody} erlaubt die Ausführung der Aktion ohne
-besonderen Sicherheitskontext.
-Neue Sicherheitsrichtlinien der Form \texttt{input\_policy::Security<\textit{T}>} lassen sich
-nutzen, indem eine Klasse \textit{T} eingeführt wird, die eine Methode\\
-\makebox[1cm]{}\texttt{static bool allow(InputEventContext const*)}\\
-besitzt, an die die Entscheidung, ob eine Aktion zuzulassen ist, delegiert wird.
-
-Der zu implementierende Eingabehandler braucht weiterhin eine Implementierung der abstrakten
-Methode\\
-\makebox[1cm]{}\texttt{virtual void handle(InputEvent const\&, InputEventContext const*)},\\
-in der die entsprechende Aktion ausgeführt wird.
-
-Die Aufnahme des neuen Handlers in die Liste der abzuarbeitenden Handle erfolgt,
-je nachdem ob erweiterte Berechtigungen zur Bearbeitung notwendig sind,
-in einer der Dateien \texttt{privilegedHandlerChain.cpp} oder \texttt{unprivilegedHandler\-Chain.cpp}
-in \texttt{src/input}, wo dem Kettenaufruf eine Zeile der Form\\
-\makebox[1cm]{}\texttt{.add<\textit{Handler}>()}\\
-hinzugefügt wird.
-Die Verwendung des Präprozessors zum Ausschluss von Handlern, die auf dem
-Zielsystem nicht lauffähig sind, ist an dieser Stelle nicht notwendig und wird durch die
-\texttt{Require}-Richtlinie umgesetzt.
-Notwendig ist lediglich, die Übersetzung des Handlers auf inkompatiblen Systemen zu verhindern.
-Dies kann mit Hilfe des Build-Systems oder durch die Klammerung der gesamten Übersetzungseinheit
-in Präprozessorbedingungen geschehen.
-
-Eine API-Referenz zur libpvsinput (Stand: 4.~November~2010) findet sich im Projektwiki.
-
-\section{Netzwerkkommunikation}
-\index{Netzwerkkommunikation}
-
-\subsection{PVS-Protokoll}
-\index{Protokoll!PVS} \index{Protokoll}
-Im Zuge der Entwicklung des PVS wurde ein sehr einfaches Messagingprotokoll entwickelt.
-Die Nachrichten bzw. Messages bestehen dabei aus Header, Nachrichtentyp, Ident und dem eigentlichen Nachrichtentext. Die einzelnen Nachrichtenteile, welche bis auf den Header selbst definiert werden können, werden verknüpft und versendet. Es sind schon Nachrichtentypen vordefiniert, welche sich nur durch unterschiedliche Dispatcher unterscheiden.
-Bereits vorhandene Typen sind COMMAND, LOGIN, MESSAGE und UNKNOWN. Die Dispatcher (\_commandDispatcher, \_loginDispatcher und \_chatDispatcher) befinden sich im Client in der Klasse \texttt{ServerConnection}, in der Steuerkonsole in der Klasse \texttt{ClientConnection} bzw. \texttt{ListenServer}. Ein Ident wie z.B. Username, Befehl oder Beschreibung des Nachrichteninhalts dient zur Unterscheidung verschiedener Nachrichten mit demselben Nachrichtentyp, wobei die Nachricht dann den dem Ident entsprechenden Nachrichtentext enthält.
-Um eine Funktion zur Behandlung einer bestimmten Nachricht zu definieren, wird diese Funktion als Handler mit dem entsprechenden Dispatcher verknüpft. Im PVS-Client beispielsweise befindet sich der Dispatcher für Nachrichten vom Typ Command in der Klasse \texttt{pvsServerConnection}, daher wird in der Klasse \texttt{pvs} die Funktion \texttt{void PVS::onCommand(PVSMsg cmdMessage)} wie folgt als Handler registriert:
-\texttt{\_pvsServerConnection->addCommandHandler("*", this, \&PVS::onCommand)}. Erhält nun der Client eine Nachricht vom Typ COMMAND, so wird die Funktion onCommand mit dem entsprechenden Nachrichtenobjekt aufgerufen. Auf die eigentliche Nachricht kann dann über die Methoden \texttt{getIdent()} und \texttt{getMessage()} des Objektes zugegriffen werden.
-
-\subsection{PVS-Messages}
-\index{Message!PVS} \index{Message}
-In Tabelle \ref{tab:messagelist} sind die Messages, die zwischen den einzelnen PVS Komponenenten ausgetauscht werden, aufgelistet.
-Der Nachrichtentyp gibt dabei an, welcher Dispatcher die Nachricht behandelt.
-Der Ident einer Nachricht wird zur Verarbeitung einer empfangenen Nachricht in der aufzurufenden Funktion benötigt (Unterscheidung von anderen Nachrichten gleichen Typs).
-
-\begin{table}
-\begin{center}
-\begin{tabular}{l | l | p{2cm} | p{4cm}}
-\label{pvs-msg-liste}
-Nachrichtentyp & Nachrichten Ident & Inhalt & Beschreibung \\
-\hline
-PVSCOMMAND & PROJECT & hostname port password quality & Hostname, Port, Passwort und Qualität des VNC Servers zu dem verbunden werden soll (durch Space getrennt) \\
-PVSCOMMAND & UNPROJECT & & \\
-PVSCOMMAND & LOCKSTATION & & \\
-PVSCOMMAND & LOCKSTATION & Message & Client mit Nachricht sperren \\
-PVSCOMMAND & UNLOCKSTATION & & \\
-PVSLOGIN & USERNAME & username & Client Benutzername \\
-PVSLOGIN & PASSWORD & password & Serverpasswort \\
-PVSLOGIN & ID & id & \\
-PVSLOGIN & FAILED & "`Wrong Password"' & Wird bei falschem Passwort gesendet \\
-PVSCOMMAND & PORT & port & \\
-PVSCOMMAND & PASSWORD & password & VNC Passwort\\
-PVSCOMMAND & RWPASSWORD & rwpassword & Passwort für den Zugriff auf die Tastatur und Maus \\
-PVSCOMMAND & VNC & YES & Erlaube Zugriff \\
-PVSCOMMAND & VNC & NO & Verbiete Zugriff \\
-PVSCOMMAND & PING & & \\
-PVSCOMMAND & VNCREQUEST & & \\
-PVSCOMMAND & VNCSRVRESULT & result code & Der Rückgabewert des pvs-vncsrv Skripts \\
-PVSCOMMAND & INPUTEVENT & Base64-kodierte InputEvent-Struktur & Fernsteuerung \\
-PVSMESSAGE & BROADCAST & MESSAGE &\\
-PVSMESSAGE & clientToAdd & & Client hinzufügen (Chat)\\
-PVSMESSAGE & clientToRemove & & Client entfernen (Chat)\\
-PVSMESSAGE & assignedName & & Festgelegter Name (Chat)\\
-\end{tabular}
-\end{center}
-\caption{Liste der PVS Messages}
-\label{tab:messagelist}
-\end{table}