diff options
Diffstat (limited to 'Konzept')
| -rw-r--r-- | Konzept/Design.txt | 4 | ||||
| -rw-r--r-- | Konzept/Konzept.txt | 4 | ||||
| -rw-r--r-- | Konzept/Netzwerk.txt | 56 |
3 files changed, 19 insertions, 45 deletions
diff --git a/Konzept/Design.txt b/Konzept/Design.txt index 2b621b3..8f8d835 100644 --- a/Konzept/Design.txt +++ b/Konzept/Design.txt @@ -2,6 +2,10 @@ Kern-Design: Netzwerk-Stack - Von allen Teilen genutze Klasse +- Server-Connection und Client-Connection-Klassen +- Server-Connections werden von einer Listener-Klasse erzeugt +- Paket-Klasse; einzelne Paket-Typen werden abgeleitet +- Nicht-blockierende Sockets (Implementierung ohne Multithreading möglich) Dämon-Manager * Wartet auf Verbindungen von Dämonen diff --git a/Konzept/Konzept.txt b/Konzept/Konzept.txt index 0a17716..9404a02 100644 --- a/Konzept/Konzept.txt +++ b/Konzept/Konzept.txt @@ -1,8 +1,6 @@ 1. Dreiteilung in Kern, Per-Host-Dämon und Client 2. Kerberos-Authentifikation zwischen den Teilen -Idee: Web-Interface statt Client? - Funktionen der Teile: @@ -14,7 +12,6 @@ Funktionen der Teile: * Status * (Statistik) * (Serververwaltung) -* (Webinterface) 2. Dämon * Verbindung zum Server zum Empfang von Befehlen @@ -42,7 +39,6 @@ Elemente des Kerns: * System-Backend (Server-Status) * Log-Verwaltung (Backend: MySQL?) - der Kern sollte alle größeren Aktivitäten loggen -* (Webinterface: PHP oder Mini-Server?) Elemente des Dämons: * System-Backend (Verwaltung & Statusinformationen, Logging) diff --git a/Konzept/Netzwerk.txt b/Konzept/Netzwerk.txt index bed00ce..5b18bfd 100644 --- a/Konzept/Netzwerk.txt +++ b/Konzept/Netzwerk.txt @@ -1,69 +1,43 @@ Ideen zum Netzwerkstack: -Alles TLS-verschlüsselt? +Alles TLS-verschlüsselt. Initalisierung der Verbindung: -Client -> Server -+---+---+---+---+-------+---------------------+---------------------+ -| 1 | 2 | 3 | 4 | 5 - 6 | 7 | 8 | -+---+---+---+---+-------+---------------------+---------------------+ -|'M'|'A'|'D'| 0 |Version|min. Protokollversion|max. Protokollversion| -+---+---+---+---+-------+---------------------+---------------------+ +Client/Dämon -> Server ++---+---+---+-------+-------+---------------------+---------------------+ +| 1 | 2 | 3 | 4 | 5 - 6 | 7 | 8 | ++---+---+---+-------+-------+---------------------+---------------------+ +|'M'|'A'|'D'|'C'/'D'|Version|min. Protokollversion|max. Protokollversion| ++---+---+---+-------+-------+---------------------+---------------------+ -Server -> Client +Server -> Client/Dämon +---+---+---+---+-------+----------------+---+ | 1 | 2 | 3 | 4 | 5 - 6 | 7 | 8 | +---+---+---+---+-------+----------------+---+ |'M'|'A'|'D'| 0 |Version|Protokollversion| 0 | +---+---+---+---+-------+----------------+---+ -8er Gruppen schön oder unnötig? - Datenpakete: -+-------------------+----------+-----------------------+----- -| 1 - 2 | 3 - 4 | 5 - 8 | 9 - ... -+-------------------+----------+-----------------------+----- -|Typ des Datenpakets|Request-ID|Größe der Nutzdaten (*)|Nutzdaten -+-------------------+----------+-----------------------+----- - -* (könnte abhängig vom Typ auch weggelassen werden) - -Frage: Verwaltet der Server die Request-IDs? Sollten Clients also beim Server eine Request-ID erfragen, wenn sie was anderes schicken wollen? Brauchen wir überhaupt Request-IDs oder reicht es, wenn immer bekannt ist, von wem und an wen ein Paket ist? - -Möglichkeit: Jedes Teil verwaltet seine eigenen Request-IDs, und insgesamt wird ein Request durch Quelle und ID identifiziert; dann bräuchten Clients nicht extra nach IDs zu fragen. - - -Anfrage an Dämon vom Client: - -+------------------+----------+--------+-------------------+-----------------------+----- -| 1 - 2 | 3 - 4 | 5 - 6 | 7 - 8 | 9 - 12 | 13 - ... -+------------------+----------+--------+-------------------+-----------------------+----- -|Typ: Dämon-Anfrage|Request-ID|Dämon-ID|Typ des Datenpakets|Größe der Nutzdaten (*)|Nutzdaten -+------------------+----------+--------+-------------------+-----------------------+----- - -Dämon-ID: Der Kern nummeriert die Dämonen einfach durch; die Liste der möglichen Dämonen wird vorher festgelegt durch eine Konfigurationsdatei - -I. Bei dieser Möglichkeit würde der Kern nur die Kapselung entfernen und das Paket an den Client weiterleiten. Wäre es vielleicht sinnvoller, wenn es nicht nur einen Typ "Dämon-Anfrage" gibt, sondern manche Typen zu Anfragen vom Kern an Dämonen führen? Das würde Caching, etc. durch den Server ermöglichen. ++-------------------+----------+-------------------+----- +| 1 - 2 | 3 - 4 | 5 - 8 | 9 - ... ++-------------------+----------+-------------------+----- +|Typ des Datenpakets|Request-ID|Größe der Nutzdaten|Nutzdaten ++-------------------+----------+-------------------+----- -II. Enthält noch keine Möglichkeit zum Multicast + Jeder Client/Dämon und der Kern verwalten ihre eigenen Request-IDs, und insgesamt wird ein Request durch Quelle und ID identifiziert. Mögliche Pakettypen: -* Keep-Alive (unnötig?) -* Request-ID-Anfrage? * Login-Anfrage -> Übertragung von Kerberos-Daten * Login-Antwort * Dämon-Discovery -* Anfrage an Dämon(en) (Multicast möglich) (Kapselt anderes Paket) -> wird weitergeleitet -* Antwort von Dämon(en) (Antwort von Multicast zusammenfassen?) (Kapselt anderes Paket) -> zurück zum Client - - siehe oben: Einfache Kapselung sinnvoll? -* Status-Anfrage +* Status-Anfrage (an Kern/Dämon) * Status-Antwort * Kommando (Shutdown, etc.) * Kommando-Antwort |