[or-cvs] r18398: {} Adding a translated version of the projects/lowbandwidth.wml (website/trunk/projects/de)

unicorn at seul.org unicorn at seul.org
Thu Feb 5 08:32:52 UTC 2009


Author: unicorn
Date: 2009-02-05 03:32:51 -0500 (Thu, 05 Feb 2009)
New Revision: 18398

Added:
   website/trunk/projects/de/lowbandwidth.wml
Log:
Adding a translated version of the projects/lowbandwidth.wml to the de pages. Unfortunately, the english page was updated during translation, therefore it is not the newest revision. Will change that soon...

Added: website/trunk/projects/de/lowbandwidth.wml
===================================================================
--- website/trunk/projects/de/lowbandwidth.wml	                        (rev 0)
+++ website/trunk/projects/de/lowbandwidth.wml	2009-02-05 08:32:51 UTC (rev 18398)
@@ -0,0 +1,318 @@
+## translation metadata
+# Based-On-Revision: 18017
+# Last-Translator: mail %a_t% oliverknapp.de
+
+#include "head.wmi" TITLE="NLnet Projekt: Tor für Clients mit wenig Bandbreite" CHARSET="UTF-8"
+
+<div class="main-column">
+
+<!-- PUT CONTENT AFTER THIS TAG -->
+
+<h2>NLnet Projekt: Tor für Clients mit wenig Bandbreite</h2>
+<hr />
+
+<p>Tor ist momentan nur von Benutzern mit einer breitbandigen
+Internetverbindung nutzbar. Beim Start von Tor wird eine große Datei mit
+Informationen über alle Server heruntergeladen. Diese Datei ist das sogenannte
+Tor-Verzeichnis und ermöglicht dem Client Tor-Server für eine Route durch das
+Netzwerk auszuwählen. Das aktuelle Tor-Protokoll benötigt dafür das gesamte
+Verzeichnis. Die Datei ist allerdings viel zu groß für Nutzer mit Modem oder
+mobilen Datendiensten wie GPRS, da dieser initiale Download der bei jedem
+Torstart nötig ist, bei solch einer langsamen Leitung zwischen 10 und 30
+Minuten dauert. Daraus folgt, dass Tor für Benutzer die mit Modem oder via
+GPRS surfen, nicht benutzbar ist. Eines der Hauptziele von Tor ist es, Menschen
+in Diktaturen oder repressiven Staaten einen sicheren, anonymen Internetzugang
+zu bieten. Diese Menschen haben aber oft eine sehr langsame Internetverbindung,
+ sei es, weil sie ein Modem nutzen müssen, oder weil die Länder nur
+schmalbandig an das Internet angeschlossen sind. Wenn man diesen Menschen den
+Zugang zu Tor ermöglicht, ist dies ein großer Fortschritt für die Freiheit
+dieser Länder./p>
+
+<p>Um Tor auch für Nutzer mit schmalbandigen Verbindungen benutzbar zu machen,
+benötigen wir eine neue Version des Torprotokolls, was die anfängliche
+Downloadmenge reduziert. Diese neue Protokollversion soll die Art und Weise
+verändern, in der ein Client die Informationen für die initiale
+Verbindungsherstellung empfängt, damit der Download auch über ein 14,4 kbps
+Modem innerhalb von 3 Minuten geschieht. Die Arbeit, die an diesem Vorschlag
+gemacht wird, hat als Endziel, dass diese Protokollveränderung innerhalb von
+12 Monaten umgesetzt ist und an die Endnutzer verteilt werden kann. Die aus
+dem Projekt entstehende Software wird unter der 3-Clause BSD Lizenz
+veröffentlicht, wie auch der Rest des Tor Codes. Alle Zwischenstände werden
+öffentlich sein.</p>
+
+<p>
+Dieses Projekt wird großzügigerweise gesponsert von:
+</p>
+
+<p>
+<a href="http://www.nlnet.nl/news/2008/20080514-awards.html">
+<img src="$(IMGROOT)/nlnet-160x60.png" alt="Der NLnet Stiftung" /></a>
+</p>
+
+<table width="100%" border="0" cellspacing="0" cellpadding="3">
+<thead>
+<tr>
+<th><big>Projekt</big></th>
+<th><big>Fälligkeit</big></th>
+</tr>
+</thead>
+
+<tr bgcolor="#e5e5e5"> <td> <b>Etappe A:</b> Design und Überprüfung der
+Protokollveränderung.<br /> <small><em>Diese Etappe enthält das detaillierte
+Design und eine simulationsbasierte Überprüfung der notwendigen Veränderungen
+und Modifikationen am aktuellen Torprotokoll. Die Veränderungen am Protokoll
+sind recht tiefgehend und müssen daher genaustens auf mögliche Gefahren für
+die Sicherheit und Anonymität des Tor-Netzes überprüft werden. Für diese
+Etappe sind 2 Monate eingeplant, die von einem intensiven, externen
+Überprüfung abgeschlossenn wird. Ein Teil von Etappe A wird es auch sein, eine
+Zielsetzung für die Geschwindigkeitssteigerung in der Implementierungsphase zu
+definieren. Das Designziel ist es, dass Tor-Verzeichnis welches initial
+runtergeladen werden muss auf etwa 300 Kilobytes zu verkleinern, was einem
+User mit einer 14,4 Kbps Leitung erlauben würde, es in etwa 3 Minuten
+runterzuladen. Sollte es für die Sicherheit oder Anonymität notwendig sein,
+können von diesem Ziel Abstriche gemacht werden, allerdings ist es das Ziel,
+auf das wir hinarbeiten. </em></small> </td> <td> 15. Juli 2008 </td> </tr>
+
+<tr> <td> <b>Etappe B:</b>Umsetzung der Protokollveränderung<br /> <small><em>
+Nach Design, Überprüfung und externer Kontrolle müssen die Veränderungen
+umgesetzt und in die aktuelle Torcodebasis eingepflegt werden. Die eigentliche
+Umsetzung der Veränderungen wird etwa 3 Monate dauern. </em> </small> </td>
+<td> 15. Oktober 2008 </td> </tr>
+
+<tr bgcolor="#e5e5e5"> <td> <b>Etappe C:</b>Tests<br /> <small><em>Da die
+Veränderung hochkritisch für die Sicherheit und Anonymität des Tornetzwerks
+ist, erfordert sie umfangreiche Überprüfung und Fehlersuche unter Labor- und
+Realbedingungen. Eine Dauer von 3 Monaten ist für die Tesphase vorgesehen, in
+der der verantwortliche Entwickler einen Drittel seiner Zeit mit Testen
+verbringt. Ein Teil der Testphase wird auch ein öffentlicher Betatest sein.
+</em></small> </td> <td> 15. Januar 2009 </td> </tr>
+
+<tr> <td> <b>Etappe D:</b>Veröffentlichung<br /> <small><em>Die eigentliche
+Veröffentlichung wird mit dem normalen Veröffentlichungsplan von Tor
+abgestimmt. Da dieses Projekt von mehreren externen Faktoren, wie der
+Fertigstellung anderer Softwareprojekten, die in die gleiche Version eingebaut
+werden sollen, abhängt, kann die Zeit zwischen Veröffentlichung und die Zeit
+bis die Veränderung von den meisten Serverbetreibern installiert wurde,
+abweichen. Die Veröffentlichung wird innerhalb des normalern
+Veröffentlichungsplans von Tor stattfinden. Dabei handelt es sich um eine
+stetige Arbeit, die von vielen Freiwilligen und Personal das von anderen
+Sponsoren bezahlt wird, durchgeführt wird. </em></small> </td> <td> 15. April
+2009 </td> </tr> </table>
+
+<br />
+
+<a id="Reports"></a> < h2><a class="anchor" href="#Reports">Monatliche
+Statusberichte</a></h2> <p>Es wird insgesamt 8 monatliche Statusberichte
+geben. Beginnend mit der ersten Etappe am 15. Juli 2008, endend mit dem
+Abschluss der Umsetzung und der Tests am 15. Januar 2009. </p>
+
+<table width="100%" border="0" cellspacing="0" cellpadding="3">
+<thead>
+<tr>
+<th><big>Monat,</big></th>
+<th><big>Statusbericht</big></th>
+</tr>
+</thead>
+
+<tr bgcolor="#e5e5e5">
+  <td>
+    <a id="Jun08"></a>
+    <a class="anchor" href="#Jun08">Juni 08</a>
+  </td>
+
+<td> <small><em>Wir haben einige anfängliche Messungen von Tor-Clients beim
+Starten gemacht. Die Ergebnisse sind nicht unbedingt überraschend: Ein Client
+holt sich etwa 10 KB Zertifikate, einen unterschriebenen Netzwerkstatuss mit
+140 KB (jetzt nur noch 90 KB, siehe nächster Abschnitt) und etwa 1,5 MB
+Serverbeschreibungen (nach der Hälfte davon beginnt er mit dem
+Pfadaufbau).</em></small> <br />
+
+<small><em><a
+href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">
+Vorschlag 138</a> verkleinert den Netzwerkstatus um etwa 30-40% und wurde bereits
+umgesetzt und in die Spezifikationen übernommen. Die Umsetzung ist Teil der
+0.2.1.x-alpha Versionen und wird Effekt zeigen, sobald mehr als zwei Drittel
+der Verzeichnisauthoritäten (also 5 von 6) auf diese Version gewechselt
+haben.</em></small> <br />
+
+<small><em><a
+href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">
+Vorschlag 140</a> hängt nicht direkt mit der anfänglich zu downloadenden Menge
+zusammen, sondern versucht die folgenden Downloads für weitere
+Netzwerkstatusdokumente ein paar Byte kleiner zu machen. Der Vorschlag wurde
+bereits aufgeschrieben und an <a
+href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">or-dev
+geschickt</a>. Es gibt ein paar Fragen, die erst von anderen Torentwicklern
+beantwortet werden müssen, aber ich denke der Vorschlag könnte umgesetzt
+werden.</em></small> <br />
+
+<small><em>Der interessante Punkt wäre aber, dass die Clients nicht mehr 1,5
+MB an Serverbeschreibungen runterladen. <a
+href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">
+Vorschlag 141</a> wurde an <a
+href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">or-dev
+geschickt</a>. Es gibt vor allem 3 Sachen zu machen, so weit ich momentan
+sehen kann: wir brauchen Lastverteilungsinformationen im Netzwerkstatus
+(sollte nicht so schwer sein), wir müssen etwas einbauen, damit Tor-Clients
+Serverbeschreibungen bei Bedarf von den Servern im Pfad beziehen können,
+während Sie diesen aufbauen und wir müssen uns um die Wahl des Exits kümmern.
+Wir entwickeln immer noch Ideen für den letzten Teil; ein paar Vorschläge
+stehen bereits im Vorschlag.</em></small> </td> </tr>
+
+<tr>
+  <td>
+    <a id="Jul08"></a>
+    <a class="anchor" href="#Jul08">Juli 08</a>
+  </td>
+  
+<td> <small><em>Die Arbeit an <a
+href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">
+Vorschlag 141</a> geht weiter: Es gibt 2 grundlegende Ideen, wie man
+Lastverteilungsinformationen in den Netzwerkstatus reinbekommt: Die eine ist,
+dass die Authoritäten die Gewichte generieren, die die Clients benutzen sollen
+und das in den Status reinpacken, der andere Ansatz ist, einfach nur
+Bandbreiteninformationen aus den Serverbeschreibungen dort reinzutun. Der
+zweite Ansatz ist wahrscheinlich besser, wenn man auch <a
+href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">
+Vorschlag 140</a> mitbetrachtet, da es verhindern würde, dass sich die Nummern
+im Netzwerkstatus sehr oft ändern.</em></small> <br />
+
+<small><em>Für den Umgang mit Exitregeln schlägt <a
+href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">eine Nachricht
+auf der or-dev Mailingliste</a> vor, dass ein Hash der die Exitregeln eines
+Servers beschreibt zum Netzwerkstatus hinzugefügt wird. Das Einfügen von
+weiteren, unvorhersehbaren 160 Bits pro Knoten in den Netzwerkstatus könnte
+problematisch sein, aber da viele Exitregeln ähnlich sind, denken wir, dass
+der Status gut komprimiert werden kann. Messungen müssen noch durchgeführt
+werden.</em></small> </td> </tr>
+
+<tr bgcolor="#e5e5e5">
+  <td>
+    <a id="Aug08"></a>
+    <a class="anchor" href="#Aug08">Aug. 08</a>
+  </td>
+  
+<td> <small><em>Die Daten der Verzeichnisautoritäten und der Algorithmus wie
+daraus der Netzwerkstatus gebildet wird, wurden dahingehend geändert, dass sie
+Bandbreiteninformationen und Exitregeln beinhalten, wie das in Vorschlag 141
+dokumentiert ist. Sobald 5 von 6 Authoritäten auf eine Version die dies
+enthält (ab Revision 16554) geupgraded haben, wird der Netzwerkstatus diese
+Informationen enthalten. </em></small> </td> </tr>
+
+<tr>
+  <td>
+    <a id="Sep08"></a>
+    <a class="anchor" href="#Sep08">Sept. 08</a>
+  </td>
+  <td>
+<small><em>Leider keine neuen Informationen im September</em></small>
+  </td>
+</tr>
+
+<tr bgcolor="#e5e5e5">
+  <td>
+    <a id="Oct08"></a>
+    <a class="anchor" href="#Oct08">Okt. 08</a>
+  </td>
+  
+<td> <small><em><p>Wir haben unseren "Fertig mit der Umsetzung" Meilenstein
+diesen Monat nicht erreicht, da der Entwickler der dieses Projekt leitet, zu
+viel um die Ohren hat. Die gute Nachricht ist, dass wir einen großen Teil der
+Umsetzungsarbeit fertig haben und dieser Teil schon seit mehreren Monaten
+(genauer seit August) in Tor ist und daher schon intensiv getestet wurde. Die
+noch fehlenden Schritte sind, dass wir Clients beibringen müssen, mit Anfragen
+nach Serverbeschreibungsdateien innerhalb eines Pfades umzugehen (wofür wir
+wahrscheinlich einen neuen Zellentyp nutzen wollen, um einen ganzen Roundtrip
+zu sparen) und dann den Clients beizubringen, das auch zu machen, wenn der
+Server den sie nutzen eine Version verwendet, die aktuell genug ist. Diese
+beiden Schritte sind etwas detaillierter unter <a
+href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">
+Abschnitt 3.2 von Vorschlag 141</a> beschrieben.</p>
+
+<p>Unser neues Ziel ist es, diese beiden Teile bis Mitte November fertig zu
+haben, wenn das nicht mehr wahrscheinlich ist, werden wir unseren Zeitplan
+komplett überarbeiten und vielleicht unser Design überdenken.</p>
+
+<p>Es gibt noch viele weitere Komponenten, um die wir uns nach diesem kümmern
+wollen -- eine, über die wir uns aktuelle viele Gedanken machen, ist das
+Herunterladen von "Unterschieden" zum letzten Netzwerkstatus: <a
+href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">
+140-consensus-diffs.txt</a>. Dies könnte zum Einen Bandbreite sparen, was
+immer schön ist, wenn man das mit der Anzahl der Nutzer multipliziert, aber es
+bedeutet auch, dass wir diese eingesparte Bandbreite nutzen können, diese
+Unterschiede öfter als "alle 3 bis 4 Stunden" zu laden. Wenn die Nutzer öfter
+als jetzt aktuelle Verzeichnisinformationen haben, können sie schnellere Pfade
+bauen, da sie bessere Informationen über die Bandbreite der Server haben (was
+mit dem ersten NLnet Projekt weiter oben zusammenhängt), aber die neue
+Hauptidee ist, dass wir Server die nur kurz online sind besser nutzen können:
+Momentan muss ein Server mindestens 3 bis 4 Stunden online sein, bis er
+irgendwelche Nutzer bekommt, was eine Menge Freiwillige ausschliest, die einen
+Server betrieben wollen, aber diesen nur wenige Stunden am Stück betrieben
+können.</p>
+
+<p>Der nächste Schritt ist, dass wir die Umsetzung von Vorschlag 141 fertig
+bekommen, so dass wir ihn schnell an die Nutzer zum Testen geben können. Wir
+hoffen, das passiert bald!</p></em></small> </td> </tr>
+
+<tr>
+  <td>
+    <a id="Nov08"></a>
+    <a class="anchor" href="#Nov08">Nov. 08</a>
+  </td>
+
+<td> <small><em><p>Es scheint, als ob unser ursprüngliche Plan für das letzte
+Entwicklungsstück sowohl a) deutlich schwerer war als wir gehofft hatten und b)
+ hoffentlich viel zu viel war für das was wir eigentlich brauchen.</p>
+
+<p> Roger hat die Designdiskussion auf or-dev neugestartet: <a
+href="http://archives.seul.org/or/dev/Nov-2008/threads.html">
+http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.</p>
+
+<p>Ich glaube wir haben jetzt einen besseren Zugang zu den Optionen und
+Einschränkungen: <a
+href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html">
+http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.</p>
+
+<p>Nick wurde mit anderen Entwicklungsprojekten begraben (hoffentlich beginnt
+er damit, dass monatlich zusammenzufassen) und ich will seine Meinung über das
+weitere Vorgehen; Ich hoffe, wir suchen uns eine der einfacheren
+Vorgehensweise aus..</p>
+
+<p>Wie auch immer, die wirklich einfachen Ideen können nicht so gut skaliert
+werden. Aber ich denke sie sind gute Lückenfüller bis später -- und wer weiß.
+was sich alles bis "später" noch geändert hat.</p></em></small> </td> </tr>
+
+<tr bgcolor="#e5e5e5">
+  <td>
+    Dez 08
+  </td>
+  <td>
+  </td>
+</tr>
+
+<tr>
+  <td>
+    Jan 09
+  </td>
+  <td>
+  </td>
+</tr>
+</table>
+
+<br />
+
+<!-- Do we want a people section? If so, would it make sense to write what
+these people will be doing? And what exactly are these people going to
+do? :)
+<a id="People"></a>
+<h2><a class="anchor" href="#People">People</a></h2>
+<ul>
+<li><a href="<page people>#Core">Peter Palfrader</a></li>
+</ul>
+-->
+
+<!-- In the future, put links to proposal, preliminary results, etc. here -->
+
+</div><!-- #main -->
+
+#include <foot.wmi>
\ No newline at end of file


Property changes on: website/trunk/projects/de/lowbandwidth.wml
___________________________________________________________________
Added: svn:keywords
   + Author Date Id Revision
Added: svn:eol-style
   + native



More information about the tor-commits mailing list