summaryrefslogtreecommitdiffstats
path: root/Konzept/Netzwerk.txt
diff options
context:
space:
mode:
authorMatthias Schiffer <matthias@gamezock.de>2008-06-25 03:50:25 +0200
committerMatthias Schiffer <matthias@gamezock.de>2008-06-25 03:50:25 +0200
commit4da2aa187717f34a98792ca6708da959b7937998 (patch)
tree071dfd119392cd22fad82ee87481e8de36627ce5 /Konzept/Netzwerk.txt
parent2305fcbba7885e529f84742fb5d9a56fb206c650 (diff)
downloadmad-4da2aa187717f34a98792ca6708da959b7937998.tar
mad-4da2aa187717f34a98792ca6708da959b7937998.zip
Einige ?nderungen am Konzept
Diffstat (limited to 'Konzept/Netzwerk.txt')
-rw-r--r--Konzept/Netzwerk.txt56
1 files changed, 15 insertions, 41 deletions
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