Comments 28
В общем я все это к тому, что к распределенному вебу идти из этой технологии, как до холодного синтеза из нынешних технологий!
Главным образом, как разослать уведомление по сети, что часть контента обновилась и кому именно её доставить? Это далеко не такая тривиальная задача, как потоковое скачивание пачки файлов, пускай и со сложной структурой.
А мне, наоборот, проще всем клиентам разослать уведомления о разных предстоящих задачах (передачи кусков файлов и разных прочих материалов), чем саму эту передачу данных между клиентами наваять.
Уведомления-то я могу рассылать всем клиентам со своего центрального сервера (ну или с нескольких таких серверов). Под "рассылать уведомления" я имею всякие способы, включая способ "клиент сам на сервере запрашивает список обновлений". Да хоть на бумажке написал да почтовым голубем отправил. :-) Главная проблема не в этом. Главная проблема описана дальше:
А вот как мне из одного браузера переслать данные в браузер другой напрямую прямым соедениенем между браузерами мимо моих "центральных серверов" - вот это до сих пор загадка...
Я ж не могу внутри html-страницы javascript'ом запустить TCP-сервер на указанном мною порту, к которому можно было бы коннектиться хоть из другого браузера (только в нём внутри страницы тоже отсутствует возможность запускать TCP-клиентов), хоть телнетом из командной строки.
Заканчивается 1-я четверть 21-го века.
А до сих пор никто не наваял для браузеров возможности:
1. Запуск внутри html-страницы одного браузера TCP-сервера на порту ПОРТ_1
2. Запуск внутри html-страницы другого браузера TCP-клиента для подключения куда хочешь (но в данной задаче к TCP-серверу первого браузера на его порт ПОРТ_1.
Откуда скрипт второго браузера узнает IP-адрес и порт для подключения к TCP-серверу браузера первого - это уже моя задача и я её как-нибудь решу сам. Могу опять эту информацию выслать клиенту почтовыми голубями. :-)
А то понаваяли каких-то там WebRTC и главный упор делают на "пробивание NAT".
Да у меня может быть в моей задаче все браузеры будут работать на машинах с белыми IP, на которых работой через NAT даже и не пахнет. Мне только дайте возможноть запускть внутри их HTML-страниц TCP-серверы да TCP-клиенты. :-)
github.com/arvidn/libtorrent/pull/4123#issuecomment-652502633
Меня устраивает
Самый длинный торрент, который я сидил (какие-то лекции по физике, выложенные русским университетом) у меня раздавались примерно месяцев 10 (потом мне понадобилось место, извините).
Вторым вопросом является: где данные хранятся-то? В localstorage? Эм… В памяти? Эм2…
но, если будет предложено адекватное решение по хранению файлов (доступ из браузеру к файловой системе, пусть ограниченный хотя бы типами файлов и каталогом) то да
приложение 'в табе' возможно переедет в приложение в браузере (без таба) по типу тех же месседженеров (как работает hangout в chromium).
Как удержать клиента в табе после завершения просмотра?Например, смотришь очередной фильм = раздаёшь все уже просмотренные.
Но вопрос хранения совершенно открыт, потому что фильмотека на сотню фильмов — это явно не localstorage в браузере.
Такие сайты, которые хостятся на компьютерах тысяч пользователей, нельзя будет ни закрыть, ни заблокировать.Ну, с этим вы, к сожалению, погорячились…
У меня кстати не заработало на совсем даже небольших файлах, после добавления магнета с rutor (в том числе и укороченного) просто ничего не происходит. Ссылку на открытый торрент с rutor тоже не смог съесть со словами Failed to fetch.
Более свежий обзор: Как скачать торрент онлайн (не устанавливая клиент сети BitTorrent)
WebTorrent используется в PeerTube который активно развивается. Но проблема WebTorrent'а в том что он не может связываться с классическими BitTorrent клиентами поскольку использует WebRTC. Эту проблему пытаются решить в BitTorrent клиентах добавляя поддержку WebRTC.
Из обзора по ссылкам возвращается код ответа 101. Рабочий вариант через облако https://webtor.io/
WebTorrent: торренты через браузер. Без плагинов, чистый JavaScript