projects/pl/lowbandwidth.wml (537bde6a7) - tor-webwml.git

lowbandwidth.wml

## translation metadata
# Based-On-Revision: 15959
# Translation-Priority: 3-low
# Last-Translator: bogdandr_at_op . pl

#include "head.wmi" TITLE="Projekt NLnet: Tor dla klientów o wolnym łączu" CHARSET="UTF-8"

<h2>Projekt NLnet: Tor dla klientów o wolnym łączu</h2>
<hr />

<p>
System Tor jest w tej chwili najbardziej nadający się do używania dla ludzi mających połączenie z
Internetem o dużej przepustowości. W czasie uruchamiania klienta Tora pobierany jest
ogromny plik z opisem wszystkich serwerów Tora. Ten plik to tak zwany Katalog Tora i
umożliwia on klientowi wybieranie spośród serwerów w sieci Tora. Pobieranie całego katalogu
jest wymagane w bieżącej wersji protokołu Tora. Ten plik z katalogiem jest zbyt duży dla
użytkowników z modemami lub będącymi w sieciach mobilnych jak GPRS, jako że wstępne
pobieranie uruchamiane przy każdym logowaniu użytkownika trwa od 10 do 30 minut na
wolnym połączeniu. W wyniku tego, Tor nie jest zdatny do używania przez użytkowników modemów
lub sieci mobilnych. Jednym z głównych celów Tora jest dostarczanie bezpiecznego anonimowego
Internetu użytkownikom w krajach z dyktaturą lub represjami. Takie miejsca często mają wolne
połączenia internetowe, przez modem albo niskiej przepustowości łącza do świata zewnętrznego.
Poprzez umożliwienie tym użytkownikom używania sieci Tora można uczynić znaczny postęp
w kierunku swobodnej komunikacji i informacji w tych krajach.
</p>

<p>
By Tor nadawał się do użycia na wolnych łączach, potrzebny jest rozwój protokołu Tora,
by zmniejszyć rozmiar wstępnego pobierania. Nowa wersja protokołu Tora powinna zmienić sposób,
w jaki klient otrzymuje informacje do stworzenia obwodu tak, by pierwsze pobieranie
mogło być wykonane na linii modemowej 14.4k w czasie około trzech minut. Celem prac w tym
projekcie jest umożliwienie wprowadzenia zmian w protokole
i rozprowadzenia ich wśród użytkowników Tora w przeciągu 12 miesięcy. Stworzone oprogramowanie
zostanie wydane na 3-punktowej licencji BSD, jak cały kod Tora. Wszystkie części będą
całkowicie publiczne.
</p>

<p>
Ten projekt jest hojnie sponsorowany przez:
</p>

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Projekt</big></th>
<th><big>Czas zakończenia</big></th>
</tr>
</thead>

<tr bgcolor="#e5e5e5">
  <td>
    <b>Część A:</b> Projektowanie i sprawdzanie zmian protokołu<br />
    <small><em>W tej części zawarty jest szczegółowy projekt i oparte na symulacjach
    sprawdzenie niezbędnych zmian i modyfikacji projektu bieżącego protokołu Tora.
    Zmiany w protokole będą raczej istotne, więc wymaga to dokładnego sprawdzenia wszystkich
    możliwych skutków dla bezpieczeństwa i anonimowości sieci Tora. Dla tej fazy projektowania
    i sprawdzania przewidziany jest dwumiesięczny okres, zakończony wyczerpującą recenzją.
    Celem tej części jest m.in. zdefiniowanie wydajności do osiągnięcia w fazie implementacji.
    Celem projektowym jest zmniejszenie pobieranego rozmiaru Katalogu Tora do około
    300 kilobajtów, co umożliwiłoby użytkownikowi łącza 14.4 kbps pobranie go w ciągu około
    trzech minut. Mogą być odstępstwa od tego celu, jeśli będą wymagane do zachowania
    bezpieczeństwa i anonimowości, ale to jest obszar, w który należy celować.
    <em></small>
  </td>
  <td>
    15 Lipca 2008
  </td>
</tr>

<tr>
  <td>
    <b>Część B:</b>Implementacja zmiany protokołu<br />
    <small><em>Po projekcie, sprawdzeniu i przeglądzie, zmiany muszą zostać
    zaimplementowane i zintegrowane z bieżącym kodem Tora. Sama implementacja
    niezbędnych zmian zajmie około trzech miesięcy.
    </em></small>
  </td>
  <td>
    15 Października 2008
  </td>
</tr>

<tr bgcolor="#e5e5e5">
  <td>
    <b>Część C:</b>Testowanie<br />
    <small><em>Zmiana jest bardzo ważna dla bezpieczeństwa i anonimowości sieci Tora,
    wymaga więc dogłębnego testowania i szukania błędów w warunkach laboratoryjnych
    i rzeczywistych. Okres trzech miesięcy jest przewidziany na testowanie i usuwanie błędów,
    podczas którego odpowiedzialny za to programista poświęci 1/3 swojego czasu na testowanie.
    Część fazy testowania będzie okresem publicznej wersji beta.
    </em></small>
  </td>
  <td>
    15 Listopada 2008
  </td>
</tr>

<tr>
  <td>
    <b>Część D:</b>Wypuszczenie<br />
    <small><em>Wypuszczenie zmian do sieci serwerów Tora będzie zsynchronizowane
    z regularnymi wydaniami Tora. Jako że regularne wydania zależą od wielu
    czynników zewnętrznych, jak zakończenie innych projektów, które powinny wyjść
    w tym samym wydaniu, właściwy czas wydania i instalacji u większości operatorów
    serwerów Tora może być różny. Z doświadczenia wiemy, że można oczekiwać okresu
    od trzech do czterech miesięcy. Wydanie będzie przeprowadzone jako część regularnego
    procesu wydawania Tora, który jest działaniem wykonywanym przez wolontariuszy i
    personel wynagradzany z innych grantów przeznaczonych na projekt Tor.
    </em></small>
  </td>
  <td>
    15 Lutego 2009
  </td>
</tr>
</table>

<br />

<a id="Reports"></a>
<h2><a class="anchor" href="#Reports">Miesięczne raporty o bieżącym stanie</a></h2>
<p>
Łącznie będzie osiem miesięcznych raportów zaczynających się od pierwszej części 15. czerwca
2008 i kończących się na ukończeniu implementacji i testów 15. lutego 2009.
</p>

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Miesiąc,</big></th>
<th><big>Raport o stanie</big></th>
</tr>
</thead>

<tr bgcolor="#e5e5e5">
  <td>
    <a id="Jun08"></a>
    <a class="anchor" href="#Jun08">Czerwiec 08</a>
  </td>
  <td>
    <small><em>Przeprowadziliśmy trochę wstępnych badan uruchamiania się klienta Tora.
    Wyniki nie są zbyt zadziwiające: klient pobiera około 10kB certyfikatów, jeden
    konsensus rozmiaru 140kB (teraz 90kB, zobacz kolejny paragraf) i około 1,5MB
    deskryptorów serwerów (po pobraniu połowy zaczyna budować obwody).</small></em>
    <br />
    <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">Propozycja
    138</a> zmniejsza rozmiar konsensusu od 30% do 40% i została już zaimplementowana
    i połączona ze specyfikacją. Implementacja jest częścią drzewa 0.2.1.x-alpha
    i odniesie skutek, gdy ponad dwie trzecie serwerów katalogowych (czyli 5 z 6)
    zainstalują nową wersję.</small></em>
    <br />
    <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Propozycja
    140</a> nie jest bezpośrednio związana ze zmniejszeniem rozmiaru wstępnego pobierania,
    zamiast tego próbuje zmniejszyć kolejne pobierania dokumentów konsensusu
    i została <a href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">wysłana na
    or-dev</a>. Najpierw jest jeszcze kilka pytań wymagających odpowiedzi od innych
    deweloperów Tora, ale poza tym propozycja wydaje się być dobra i może być
    implementowana.</small></em>
    <br />
    <small><em>Wielką Sprawą jest sprawienie, by klienci nie pobierali całych 1,5MB
    deskryptorów serwerów. <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Propozycja
    141</a> została <a
    href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">wysłana na
    or-dev</a>. Składa się w chwili bieżącej z 3 podstawowych rzeczy: przenieść
    informacje o równowadze wykorzystania łącza do konsensusu (nie powinno być trudne),
    zaimplementować coś, co pozwoli klientom Tora pobieranie deskryptorów na żądanie
    od routerów na ich obwodzie w czasie jesgo budowania (opisane w szkicu), zabrać się
    za wybór punktu wyjścia. Ciągle tworzymy pomysły odnośnie ostatniej części; niektóre
    możliwości są wspomniane w szkicu.</small></em>
  </td>
</tr>

<tr>
  <td>
    <a id="Jul08"></a>
	<a class="anchor" href="#Jul08">Lipiec 08</a>
  </td>
  <td>
  <small><em>Praca nad <a
 href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Propozycją
 141</a> trwa: Są dwa podstawowe pomysły na to, jak przenieść informacje o
 równowadze wykorzystania łącza do konsensusu: jeden pomysł mówi, że centra
 katalogowe generują wagi, których klienci powinni używać i umieszczają to w
 konsensusie, drugi jest taki, by po prostu umieścić w nim informacje o łączu
 z deskryptora serwera. Ta druga opcja jest prawdopodobnie lepsza, gdy weźmie się
 też pod uwagę <a
 href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Propozycję
 140</a>, gdyż unika to dużej ilości często zmieniających się liczb w konsensusie.</em></small>
 <br />
 <small><em>Odnośnie polityk wyjścia, <a
 href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">list
 na liście mailingowej or-dev</a> sugeruje dodanie hasza identyfikującego politykę wyjścia
 węzła do dokumentu konsensusu. Dodanie kolejnych 160 bitów o wysokiej entropii na każdy
 węzeł może budzić niepokój, ale naszym zdaniem wiele polityk wyjścia jest takich samych,
 więc dokument konsensusu powinien dobrze się kompresować. Pomiary trwają.</em></small>
  </td>
</tr>

<tr bgcolor="#e5e5e5">
  <td>
    Sierpień 08
  </td>
  <td>
  </td>
</tr>

<tr>
  <td>
    Wrzesień 08
  </td>
  <td>
  </td>
</tr>

<tr bgcolor="#e5e5e5">
  <td>
    Październik 08
  </td>
  <td>
  </td>
</tr>

<tr>
  <td>
    Listopad 08
  </td>
  <td>
  </td>
</tr>

<tr bgcolor="#e5e5e5">
  <td>
    Grudzień 08
  </td>
  <td>
  </td>
</tr>

<tr>
  <td>
    Styczeń 09
  </td>
  <td>
  </td>
</tr>
</table>

<br />

</div>

#include <foot.wmi>

tor-webwml.git

Mainetance/polish translation update.