diff options
| author | Matthias Schiffer <matthias@gamezock.de> | 2008-06-11 14:01:22 +0200 |
|---|---|---|
| committer | Matthias Schiffer <matthias@gamezock.de> | 2008-06-11 14:01:22 +0200 |
| commit | 1f651812e2495e46aa5a21c354e0c322af986824 (patch) | |
| tree | 251bcfb3432e5bebcdd6a775a043fd99427fb0ef /Konzept | |
| parent | 4b6acb098be9aa41e4a4bedc9aa3655822049635 (diff) | |
| download | mad-1f651812e2495e46aa5a21c354e0c322af986824.tar mad-1f651812e2495e46aa5a21c354e0c322af986824.zip | |
Konzept und Netzwerk-Stack weiterentwickelt
Diffstat (limited to 'Konzept')
| -rw-r--r-- | Konzept/Konzept.txt | 1 | ||||
| -rw-r--r-- | Konzept/Netzwerk.txt | 34 |
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.) |