summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMatthias Schiffer <matthias@gamezock.de>2008-06-11 14:01:22 +0200
committerMatthias Schiffer <matthias@gamezock.de>2008-06-11 14:01:22 +0200
commit1f651812e2495e46aa5a21c354e0c322af986824 (patch)
tree251bcfb3432e5bebcdd6a775a043fd99427fb0ef
parent4b6acb098be9aa41e4a4bedc9aa3655822049635 (diff)
downloadmad-1f651812e2495e46aa5a21c354e0c322af986824.tar
mad-1f651812e2495e46aa5a21c354e0c322af986824.zip
Konzept und Netzwerk-Stack weiterentwickelt
-rw-r--r--Konzept/Konzept.txt1
-rw-r--r--Konzept/Netzwerk.txt34
2 files changed, 27 insertions, 8 deletions
diff --git a/Konzept/Konzept.txt b/Konzept/Konzept.txt
index 5fe7480..0a17716 100644
--- a/Konzept/Konzept.txt
+++ b/Konzept/Konzept.txt
@@ -31,6 +31,7 @@ Elemente, die von allen Teilen gebraucht werden:
* Netzwerkstack (siehe Netzwerk.txt)
* Kerberos
* Auslesen von Konfigurationsdateien
+ - sollte der Kern Teile seiner Konfiguration in einer MySQL-Datenbank ablegen?
Elemente des Kerns:
diff --git a/Konzept/Netzwerk.txt b/Konzept/Netzwerk.txt
index 4536e37..bed00ce 100644
--- a/Konzept/Netzwerk.txt
+++ b/Konzept/Netzwerk.txt
@@ -25,15 +25,32 @@ Server -> Client
Datenpakete:
-+-------------------+--------------+-----------------------+-----
-| 1 - 2 | 3 - 4 | 5 - 8 | 9 - ...
-+-------------------+--------------+-----------------------+-----
-|Typ des Datenpakets|Request-ID (*)|Größe der Nutzdaten (*)|Nutzdaten
-+-------------------+--------------+-----------------------+-----
++-------------------+----------+-----------------------+-----
+| 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?
+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.
+
+II. Enthält noch keine Möglichkeit zum Multicast
Mögliche Pakettypen:
@@ -43,8 +60,9 @@ Mögliche Pakettypen:
* Login-Anfrage -> Übertragung von Kerberos-Daten
* Login-Antwort
* Dämon-Discovery
-* Anfrage an Dämon (Kapselt anderes Paket?) -> wird weitergeleitet
-* Antwort von Dämon (Kapselt anderes Paket?) -> zurück zum Client
+* 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-Antwort
* Kommando (Shutdown, etc.)