blob: bed00ce3a96b4956210fb0bea4dafbc6a479139f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
|
Ideen zum Netzwerkstack:
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|
+---+---+---+---+-------+---------------------+---------------------+
Server -> Client
+---+---+---+---+-------+----------------+---+
| 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.
II. Enthält noch keine Möglichkeit zum Multicast
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-Antwort
* Kommando (Shutdown, etc.)
* Kommando-Antwort
* Error
+ weitere Anfragen und Antworten...
|
