Był sobie protokół. Miał kilka zalet. Decentralizacja zasobów – większa stabilność i bezpieczeństwo była pierwszą z nich. Drugą odciążanie łącz serwerów, dając użytkownikom większą, możliwą łączną przepustowość, niż ta, którą zapewniałyby one same. Trzecie zapewniało możliwość pobierania plików wszystkim, nawet jeśli nie posiadali oni zewnętrznego IP. Protokół doskonały. Co z tego, jeśli nie używany powszechnie?
Dlaczego mówię, że nie jest powszechny? Bo miast być integrowanym z innymi aplikacjami porobiło się sporo klientów, którzy to różnią się umiejscowieniem przycisków. OK, mój układ znaczków mojszy od Twojego, ale tak naprawdę ludzi interesuje tylko ustawienie prędkości, portu i folderu, do którego można pobierać. Ile osób skorzysta z zaawansowanych ustawien cache’owania, czy opcji dla DHT? Ma działać.
Dobrze, mamy klienty z dużą możliwością konfiguracji… Teraz trzeba o oprogramowanie serwerowe, zwane trackerem. I znów, jest ich pewna grupa, jedne używane poprzez serwer z obsługą skryptów, napisane przykładowo w PHP, drugie znów samodzielne – napisane np. w C/C++, czy Pythonie.
Czemu poprzednie punkty nie uważam za właściwe? Bo używanie kompatybilnych-tylko-ze-sobą rozwiązań nie jest wygodne dla administratorów. Zamiast tworzyć nowe oprogramowanie, należałoby zająć się wprowadzaniem natywnej obsługi protokołu w istniejącym.
Poczyniono kroki, prowadzące w tym kierunku. Opera ma wbudowane proste pobieranie torrentów (jest tylko kilka opcji, jednak one wystarczają). We wczesnej wersji rozwojowej mamy także moduł do serwera Apache2, mod_bt.
Propozycją dalszego wspierania protokołu w innych miejscach mógłby być bt-rsync, dzięki któremu możnaby mirrorować inne serwery, oszczędnie korzystając z ich zasobów. Na dodatek małe pliki, np. repozytoria pakietów dystrybucyjnych byłyby później dostępne poprzez http, a duże – także przez bittorrent, gdzie zasada mirrorów przełożyłaby się na ilość seedów. W dalekiej przyszłości protokół ftp całkowicie możnaby zastąpić protokołem bt.
Przykłady można mnożyć – tam, gdzie przesyłane są duże ilości informacji i może zajść podejrzenie co do łącza jako wąskiego gardła, z powodzeniem można zastosować bittorrent. Usenet, openBlueFrog ze zdecentralizowanymi, zaszyfrowanymi bazami danych sięgającymi milionów użytkowników – wiele problemów można rozwiązać w ten sposób.
Czas na poważnie zastanowić się nad przyszłością tego protokołu i zmienić nastawienie ludzi, którzy uważają, że nadaje się on tylko do ściągania warezów.
Ot, BT jest jak FTP. Niektórzy tego nie rozumieją, i narzekają, że BitTorrent (!) nie ma wyszukiwania torrentów… (oczywiście z filmami i warezami).
Ja ich prostuję 🙂
W sumie, taki windowsowy uTorrent ma search engine po popularniejszych wyszukiwarkach oraz RSS-downloader. Ale to tylko zbędne bajery. 🙂
> Bo używanie kompatybilnych-tylko-ze-sobą rozwiązań nie jest wygodne dla administratorów.
Poza Bitcometem, który ma niezgodną ze standardem implementację DHT, nie widzę jakichkolwiek niekompatybilności zarówno na linii klient<->klient, jak i klient<->tracker. Co miałeś konkretnie na myśli?
BTW, wbudowanie klienta BT w jakąkolwiek przeglądarkę www to imo pomyłka – korzystanie z czegoś takiego zmusza mnie do pozostawiania przeglądarki włączonej, gdy tylko chcę poseedować…
@firejump: To, że klienty i serwery nie współdziałały z niczym, co wymyślono poprzednio. Skoro tracker jest po http, to chciałbym mieć możliwość jego obsługi za pomocą mojego ulubionego serwera http.
Co do przeglądarki www – i tak swojej nie wyłączam, póki nie zamknę systemu, chyba, że potrzebuję chwilowo braku aktywności pamięci, procesora i dysku.
Inna sprawa, że Opera nie sprawdza przy każdym uruchomieniu poprawności danych – może zmienili to w finalnej wersji, a może celem oszczędzania czasu robi to tylko na koniec pobierania.
Update: Akurat przed chwilą, po otwarciu, Opera zaczęła sprawdzać pobierany torrent. Nie jestem pewien, czemu nie robi tego zawsze, bo jestem przekonany, że wczoraj tak nie było.