- commit changes from english version
Jens Kubieziel

Jens Kubieziel commited on 2005-09-30 10:26:42
Zeige 1 geänderte Dateien mit 15 Einfügungen und 4 Löschungen.

... ...
@@ -214,14 +214,25 @@
214 214
     viele DNS-"Arbeiter"-Threads hervorbringen. Es gibt einige
215 215
     asynchrone DNS-Bibliotheken da drau�en. Aber aus historischen
216 216
     Gr�nden sind diese voller fehler. Gibt es welche, die stabil,
217
-    schnell, sauber und Frei Software sind? Falls ja, k�nnten wir
218
-    diese in Tor integrieren. Schaue
219
-    dir <a
217
+    schnell, sauber und Frei Software sind? (Tor nutzt OpenSSL und das
218
+    ist wahrscheinlich nicht mit der GPL kompatibel. Somit sind
219
+    GPL-Bibliotheken au�en vor.)
220
+    Falls ja, k�nnten wir diese in Tor integrieren. Schaue dir <a
220 221
     href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">Agls
221
-    Posting</a> f�r einen potentiellen Ansatz an.</li>
222
+    Posting</a> f�r einen potentiellen Ansatz an. Wirf weiterhin
223
+    einen Blick
224
+    auf <a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a>
225
+    und <a
226
+    href="http://www.monkey.org/~provos/libdnsres/">libdnsres</a>.</li>
222 227
   <li>Torversionen ab 0.1.1.x unterst�tzen Cryptohardwarebeschleuniger
223 228
     via OpenSSL. Bisher hat das niemand getestet. M�chte jemand gern
224 229
     eine Karte haben und schauen, ob das funktioniert?</li>
230
+  <li>Vor einiger Zeit haben wir Unterst�tzung
231
+    f�r <code>dmalloc</code> hinzugef�gt, um Leaks zu finden. Leider
232
+    haben wir es nie geschafft, das zum Laufen zu
233
+    bekommen. Ist <code>dmalloc</code> nicht das richtige hierf�r?
234
+    Schaue dir die Konfigurationsoption <var>--with-dmalloc</var> an
235
+    und test damit herum.</li>
225 236
   <li>Weil die Torserver jede Zelle speichern und weitergeben m�ssen,
226 237
     brauchen die Torserver mit hoher Bandbreite Dutzende Megabyte an
227 238
     Speicher. Wir ben�tigen bessere Heuristiken, wenn die Buffer zu
228 239