Einige ?nderungen am Konzept

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