|
|
@@ -0,0 +1,167 @@
|
|
|
1
|
+# Homework hw9 task2
|
|
|
2
|
+
|
|
|
3
|
+[TOC]: #
|
|
|
4
|
+
|
|
|
5
|
+# Table of Contents
|
|
|
6
|
+- [1.1 Ziel](#11-ziel)
|
|
|
7
|
+- [2.1 Aufgabe](#21-aufgabe)
|
|
|
8
|
+ - [2.1.1 Optionen beim Aufruf](#211-optionen-beim-aufruf)
|
|
|
9
|
+ - [2.1.2 Verhalten des Servers bei Kommandos](#212-verhalten-des-servers-bei-kommandos)
|
|
|
10
|
+ - [2.1.4 Ausgaben des Servers auf der Konsole](#214-ausgaben-des-servers-auf-der-konsole)
|
|
|
11
|
+- [3.1 Fehlerbehandlung](#31-fehlerbehandlung)
|
|
|
12
|
+- [4.1 Tipps](#41-tipps)
|
|
|
13
|
+
|
|
|
14
|
+
|
|
|
15
|
+## 1.1 Ziel
|
|
|
16
|
+
|
|
|
17
|
+Um die bisherige Mustersuche in einem Hashwert auf mehrere Rechner
|
|
|
18
|
+auszuweiten, ist das Ziel dieser Aufgabe, einen kleinen TCP-Server zu
|
|
|
19
|
+implementieren. Die ersten Kommandos des Server haben Sie bereits in
|
|
|
20
|
+hw9:task1 implementiert.
|
|
|
21
|
+
|
|
|
22
|
+Zuvor legen wir ein [Rust Workspace][] an, in welchem wir komfortabel
|
|
|
23
|
+unsere eigenen Bibliotheken und ein Binary (den Server) verwalten.
|
|
|
24
|
+Nutzen Sie die in hw9:task1 geschriebene Bibliothek, in dem Sie diese
|
|
|
25
|
+als `srv-commands` Bibliothek in task2 benutzen, um die Kommandos an den
|
|
|
26
|
+Server zu parsen.
|
|
|
27
|
+
|
|
|
28
|
+## 2.1 Aufgabe
|
|
|
29
|
+
|
|
|
30
|
+Implementieren Sie den Webserver, in dem Sie [TCPListener][tcplistener]
|
|
|
31
|
+verwenden.
|
|
|
32
|
+
|
|
|
33
|
+Sorgen Sie in dieser ersten Ausbaustufe dafür, dass der Server
|
|
|
34
|
+Nachrichten zwischen Anfragen speichert und in der Reihenfolge zurück
|
|
|
35
|
+gibt, in der Sie gesendet wurden. ([FIFO][fifo])
|
|
|
36
|
+
|
|
|
37
|
+Der Server darf beim Herunterfahren alle Daten verlieren. In dieser
|
|
|
38
|
+Version Ihres Servers genügt es, wenn der Server nur immer eine Anfrage
|
|
|
39
|
+zu jeder Zeit beantwortet.
|
|
|
40
|
+
|
|
|
41
|
+### 2.1.1 Optionen beim Aufruf
|
|
|
42
|
+
|
|
|
43
|
+Nun zu einer weiteren Lib im Workspace: `srv-config`. Diese Lib soll
|
|
|
44
|
+einen geeigneten Config Typen bereitstellen. Das Parsen und Auswerten
|
|
|
45
|
+der beim Aufruf angegebenen Parameter geschieht komplett in dieser
|
|
|
46
|
+Library. Exportiert wird nur der Config Typ und dessen Methoden (soweit
|
|
|
47
|
+nötig). Zum Parsen verwenden Sie wieder die externe Crate [clap][].
|
|
|
48
|
+
|
|
|
49
|
+```text
|
|
|
50
|
+Multi Hash Server 0.1
|
|
|
51
|
+M. Mächtel <maechtel@htwg-konstanz.de>
|
|
|
52
|
+Does awesome things to find a hash with specific pattern
|
|
|
53
|
+
|
|
|
54
|
+USAGE:
|
|
|
55
|
+ task2 [FLAGS] [OPTIONS] [SUBCOMMAND]
|
|
|
56
|
+
|
|
|
57
|
+FLAGS:
|
|
|
58
|
+ -h, --help Prints help information
|
|
|
59
|
+ -V, --version Prints version information
|
|
|
60
|
+ -v Sets the level of verbosity
|
|
|
61
|
+
|
|
|
62
|
+OPTIONS:
|
|
|
63
|
+ -a, --address <ADDRESS> the address, where the server can be reached (127.0.0.1 is default)
|
|
|
64
|
+ -p, --port <PORT> the port, where the server can be reached (7878 is default)
|
|
|
65
|
+
|
|
|
66
|
+SUBCOMMANDS:
|
|
|
67
|
+ help Prints this message or the help of the given subcommand(s)
|
|
|
68
|
+ test controls testing features
|
|
|
69
|
+```
|
|
|
70
|
+
|
|
|
71
|
+#### 2.1.1.1 `-v` Option
|
|
|
72
|
+
|
|
|
73
|
+Mit der `-v` Ausgabe gibt der Server folgende Informationen aus:
|
|
|
74
|
+
|
|
|
75
|
+- Beim Starten des Servers die Parameter, mit denen er läuft (verbose,
|
|
|
76
|
+ port, address, test, ...)
|
|
|
77
|
+- Den CONTROL-String, den der Server im CONTROL Kommando empfangen hat.
|
|
|
78
|
+
|
|
|
79
|
+Benötigen Sie darüber hinaus weitere Ausgaben, so geben Sie diese bitte
|
|
|
80
|
+nur bei -vv, -vvv usw. aus.
|
|
|
81
|
+
|
|
|
82
|
+#### 2.1.1.2 `-a` Option
|
|
|
83
|
+
|
|
|
84
|
+TODO
|
|
|
85
|
+
|
|
|
86
|
+#### 2.1.1.3 `-p` Option
|
|
|
87
|
+
|
|
|
88
|
+TODO
|
|
|
89
|
+
|
|
|
90
|
+#### 2.1.1.4 `test` Option
|
|
|
91
|
+
|
|
|
92
|
+Wird diese Option mit angegeben, dann erstellt der Server automatisch 3
|
|
|
93
|
+Nachrichten, die durch das **RETRIEVE** Kommando abgerufen werden können.
|
|
|
94
|
+
|
|
|
95
|
+### 2.1.2 Verhalten des Servers bei Kommandos
|
|
|
96
|
+
|
|
|
97
|
+- **STAGE**: Der Server speichert die Nachricht
|
|
|
98
|
+- **COMMAND**: Der Server wertet das Kommando aus, speichert es aber
|
|
|
99
|
+ nicht! Die Ausführung von Kommandos ist in dieser Aufgabe noch nicht
|
|
|
100
|
+ zu implementieren.
|
|
|
101
|
+- **RETRIEVE**: Der Server gibt die älteste Nachricht zurück. Die
|
|
|
102
|
+ Nachricht steht danach auf dem Server nicht mehr zur Verfügung.
|
|
|
103
|
+
|
|
|
104
|
+
|
|
|
105
|
+### 2.1.4 Ausgaben des Servers auf der Konsole
|
|
|
106
|
+
|
|
|
107
|
+Eventuell Auftretende Fehler gibt der Server auf der Konsole aus, ohne
|
|
|
108
|
+das Programm zu beenden.
|
|
|
109
|
+
|
|
|
110
|
+Wird die Option -v angegeben, dann gibt der Server zusätzlichen
|
|
|
111
|
+Informationen aus (siehe obiges Kapitel dazu).
|
|
|
112
|
+
|
|
|
113
|
+
|
|
|
114
|
+## 3.1 Fehlerbehandlung
|
|
|
115
|
+
|
|
|
116
|
+Wie bereits mehrfach erwähnt, geschieht auch in Rust die
|
|
|
117
|
+Fehlerbehandlung wie mit Javas checked Exceptions, in dem spezielle
|
|
|
118
|
+Fehler und Ergebnisse in generische Fehler und Ereignisse umgeformt
|
|
|
119
|
+werden, um diese dann nach 'oben' durch zureichen. Auf der höchsten
|
|
|
120
|
+Ebene werden dann die Fehler behandelt. Bei Rust kommt noch dazu, dass
|
|
|
121
|
+man Results auch lokal in einer Funktion kombiniert, um dann alle Fehler
|
|
|
122
|
+innerhalb dieser Funktion (Top-level Handler) behandelt.
|
|
|
123
|
+
|
|
|
124
|
+Als Basiswerkzeug haben Sie dazu bereits die Traits
|
|
|
125
|
+`[std::convert::From][]` und `[std::convert::Into][]` kennen gelernt. Es
|
|
|
126
|
+genügt eines davon zu implementieren.
|
|
|
127
|
+
|
|
|
128
|
+Wenn man aber nicht einfach nur Fehler durchreichen möchte, sondern
|
|
|
129
|
+volle Results, muss man von Result<T,E> zu dem entsprechenden
|
|
|
130
|
+Result<U,F> der aufrufenden Funktion kommen. Dazu kann man zu
|
|
|
131
|
+'Result-Kombinatoren' greifen. Die Funktion `map` wandelt den Ok-Typ in
|
|
|
132
|
+einen anderen um, `map_err` wandelt den Fehlertyp. Möchte man also
|
|
|
133
|
+beides, sieht der Aufruf folgendermaßen aus:
|
|
|
134
|
+
|
|
|
135
|
+```rust
|
|
|
136
|
+res.map(....).map_err(....)
|
|
|
137
|
+```
|
|
|
138
|
+
|
|
|
139
|
+Das ist derzeit noch 'aufwendig' als Syntax zu schreiben, entsprechende
|
|
|
140
|
+RFC's um dies zu vereinfachen existieren bereits (vgl. Evolution der
|
|
|
141
|
+Fehlerbehandlung in Rust: match()->try!->?).
|
|
|
142
|
+
|
|
|
143
|
+Ihre Lösung dieser Aufgabe hat somit idealerweise einen eigenen
|
|
|
144
|
+Fehlertypen, der wiederum den 'ParseError'-Typen aus hw9:task1 als auch
|
|
|
145
|
+den/die in dieser Aufgabe auftretende Fehlertypen enthält.
|
|
|
146
|
+
|
|
|
147
|
+
|
|
|
148
|
+
|
|
|
149
|
+## 4.1 Tipps
|
|
|
150
|
+
|
|
|
151
|
+* Zum Speichern eignet sich die [VecDeque][vecdeque], mit der sich das oben genannte FIFO-Verhalten gut abbilden lässt.
|
|
|
152
|
+* Früher an später denken: gut Aufteilung von Aufgaben in Funktionen macht die folgenden Aufgaben einfacher.
|
|
|
153
|
+* Zum Testen eignet sich netcat:
|
|
|
154
|
+
|
|
|
155
|
+```
|
|
|
156
|
+echo "STASH My privat hash: :) !" | nc 127.0.0.1 7878
|
|
|
157
|
+echo "COMMAND Beam me up!" | nc 127.0.0.1 7878
|
|
|
158
|
+echo "RETRIEVE" | nc 127.0.0.1 7878
|
|
|
159
|
+```
|
|
|
160
|
+
|
|
|
161
|
+[tcplistener]: https://doc.rust-lang.org/std/net/struct.TcpListener.html
|
|
|
162
|
+[fifo]: https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)
|
|
|
163
|
+[vecdeque]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html
|
|
|
164
|
+[std::convert::From]: https://doc.rust-lang.org/std/convert/trait.From.html
|
|
|
165
|
+[std::convert::Into]: https://doc.rust-lang.org/std/convert/trait.Into.html
|
|
|
166
|
+[Rust Workspace]: https://doc.rust-lang.org/book/second-edition/ch14-03-cargo-workspaces.html
|
|
|
167
|
+[clap]: https://docs.rs/clap/
|