Skoro moim projektem jest ElTorrento – klient BitTorrent to pora napisać trochę więcej o samym BitTorrent. Jeszcze nietechnicznie, bo nie ma sensu uczyć się rzeczy na pamięć teraz, skoro za kilka dni/tygodni i tak będzie się je wykorzystywało w praniu. To co chcę dzisiaj zrobić to robić BitTorrent na elementy, z których się składa. To także umożliwi mi potem trochę lepszą organizację kodu – jak i w ogóle pomysł na jej organizację, bo na razie nie mam żadnego.

W sieci znalazłem dwa podstawowe dokumenty, na bazie których będę budował mojego własnego klienta BitTorrent. Pierwszym i bardzo fajnie napisanym jest nieoficjalna specyfikacja. Drugim oficjalna specyfikacja (plus dodatkowe linki ze strony). Warto też przeczytać ogólnie o BitTorrent na wikipedii. To jest tak zwana wiedza bazowa. W sieci można znaleźć dużo informacji o tym jak zbudować klienta i jak to inni robili. Jeżeli będę miał jakieś wątpliwość lub coś dla mnie będzie nie jasne to na pewno tam zajrzę.

Także na github znalazłem parę projektów, więc ogólnie referencji jest na tyle dużo, że zdziwiłbym się gdybym samym copy-paste nie napisał całego projektu ;) Dlatego też staram się tam nie zaglądać. Naprawdę się STARAM :)

To co udało mi się wydzielić jako elementy BitTorrent to:

  1. Bencode
  2. Plik torrent
  3. Trackers
  4. Peers
  5. Klient

Bencode

Sposób kodowania i rozszyfrowywania informacji w BitTorrent, zarówno informacji zawartych w plikach Torrent, jak i informacji przesyłanej siecią. Bez tego ani rusz. Więc wyciągnąłem to przed nawias :)

Pliki torrent

Jest to zbiór wszystkich informacji jakie są niezbędne by protokół BitTorrent mógł działać poprawnie. Bez informacji w pliku nie bylibyśmy wstanie wiedzieć do którego Tracker się odwołać, jakie pliki są zawarte i ile ona zajmują oraz jak są podzielone na fragmenty (pieces).

Taki plik zawiera wszystko co jest potrzebne by móc w pełni pobrać pliki. Wystarczy więc dzielić się tym jednym plikiem i każdy kto go ma będzie mógł ściągnąć te same informacje.

Trackers

To taki byt, który zarządza użytkownikami (peers) którzy ściągają dany plik. Jego główną rolą jest łączenie użytkowników i pozwalanie im na nawiązanie połączenia – z pewnymi parametrami where jak chociażby czy dany peer zawiera odpowiednie dane które potrzebuje (pieces). Łącząc się do trackera, wysyłamy informację o tym jakie fragmenty plików posiadamy (pieces), dzięki czemu tracker może innemu peer przedstawić losowo wybraną listę peers którzy zawierają pieces wymagane przez dany peer.

Tracker nie musi koniecznie posiadać super aktualnych informacji. To znaczy, może przekazać informację na temat tego, że jeden peer zawiera niezbędne pieces ale my nie mamy gwarancji, że się do tego peer podłączymy.

Implementacja tracker jest poza zakresem projektu, ale możliwe, że jak się wszystko uda to i trackera można by napisać :)

Peers

To są użytkownicy biorący udział w komunikacji z tracker i mogą zawierać fragmenty plików (pieces). Jeżeli taki peer zawiera pełny plik to nazywamy go seed. Peers cały czas kolejkują pieces do ściągnięcia i komunikują się z tracker w celu pobrania listy możliwych peers dla określonych fragmentów plików.

Klient

Klient to aplikacja, która ma zaimplementowany protokół BitTorrent i jest odpowiedzialna za zarządzanie interakcjami między trackers i peers oraz za zapisywanie i odczytywanie plików na komputerze. Klient też jest odpowiedzialny za otwarcie połączenia na określonym porcie. Jeden port per plik torrent.

Podsumowanie

To tyle takiego większego overview. Nie ma szczegółów, ale już widać pewne rzeczy które się wyróżniają. Ciekawa informacja jest na temat pieces bo to mi wygląda jak idealne zadanie dla procesu w elixir.

Nie mogę się częściowo doczekać tej całej implementacji :) Będzie się działo! :)

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

3 KOMENTARZE

  2. Wchodząc liczyłem właśnie na te techniczne szczegóły, a nie “bittorent dla opornych”. “Implementacja tracker jest out-of-scope projekt, ” – po jakiemu to? Raz wstawiasz angielskie słowa bez odmiany, później te same odmieniasz, albo nie odmieniasz polskich występujących po angielskich. Ciężko się to czyta.

    • szczegóły będą – podczas implementacji. Teraz jest widok odgórny. nie ma sensu wchodzić w szczegóły i nimi sobie głowy zawracać jak się ich jeszcze nie implementuje. A peer, peers, tracker, trackers o pieces to jest specjalnie i może być ciężko, ale nomenklatura protokołu powinna pozostać nie zmieniona. No chyba, że ktoś zrobi polską wersję protokołu. Więc pewnie masz rację, że się ciężko czyta.

      tak, miało być projektu a nie projekt – już poprawiam, zgubiłem literówkę. a literówki będą się zdarzać. mam dysleksję i już 8 lat temu doszedłem do wniosku, że albo mogę nic nie pisać albo pisać tak jak mi to wychodzi z założeniem najlepszej jakości jaką ja jestem wstanie dostarczyć nie płacą za korektę.

Comments are closed.