Pull to refresh

Comments 33

Заметил, что когда пытаются представить p2p просмотр видео или аудио во время загрузки, как бы невзначай в списках источников всегда крутится какой-нибудь веб-сервер или несколько. Особенно этим грешат разработчики Bittorrent/utorrent, все их рекламные демонстрации так или иначе вытягивались за уши с помощью веб-сида.
Ваш механизм хорош, но есть несколько но. Мне кажется, что с веб-источников загрузка должна идти всегда последовательно (в смысле закачивать последовательно все незагруженные блоки). Потому что:
1. Это самый надёжный источник который не отключится в самый неожиданный момент просмотра
2. Скорость с веб-источника всегда постоянна
3. Порой веб-источник — это единственный источник на раздаче со 100%.

Некоторые интересные моменты с вашими магнет-ссылками:
Магнит для Торрента (Magnet for Torrent)
magnet:?xt=urn:btih:.........&ws=http…
прикол заключается в том, что чтобы пошла загрузка с веб-источника данные торрент-файла вначале должен отдать обычный торрент пир. Программисты utorrent в своё время хотели решить эту проблему, во времена utorrent 3.0 был придуман параметр fl. Торрент клиент должен был обращаться к веб-серверу по указанной в данном параметре http ссылке и получить данные торрент-файла. У кого сейчас стоит utorrent 3.4.2 можете перетащить любой файл в окошко программы utorrent, после чего вас направят на специально созданную страничку с такой вот не работающей магнет-ссылкой.
Магнит для DC++ (Magnet for DC++)
magnet:?xt=urn:tree:tiger:............&xs=http://cache.freebase.be/jqtbb6eblho33eaa5o6pplnacm6bbata
а какой DC клиент сейчас способен понять ссылку на кеш источников? Вроде таких нет ещё пока.
Frebase не для DC а для Gnutella2. Для DC подходит xs=dchub:// вконце магнита но я не стал встраивать чтобы не нагружать никакой хаб.

А за параметр fl спасибо. Где бы ещё доки о нём почитать. Я как раз думал о том как же они справляются когда ни одного сида.
Если узнаете как работfет fl отпишитесь тут. Первоначально по нему можно было даже торрент-файл скачать. Сейчас вроде как utorrent вообще ни как не реагирует на fl.
Я использую Qbittorrent. Там есть 2 галочки. Загружать 1 и последний кусок. И загружать последовательно.
Ставим 2ю галочку сразу. Через 10 секунд первую.
Скорость у меня 100 мбит. Обычно все раздачи качаются на 70-80 мбит (поставил ограничение) на такой скорости причем без разницы в каком порядке качать.
Сейчас скорости такие большие, что торрент который выложен в сеть уже через 15 минут раздается нужным людям и остальные могут качать последовательно без проблем и упадка в скорости.
Алгоритм:

1 Если (скорость загрузки файла меньше заданного битрейта)
то файл загружается случайным порядком;
2 Иначе
Если (скорость загрузки непрерывного участка от начала файла меньше или равна битрейту)
то файл загружается последовательно;
Иначе
файл загружается случайно;


Мой внутренний компилятор завис. Чтобы сравнить выделенные величины, их нужно измерить. То есть загрузить. Вопрос: загружать последовательно или случайно?
И еще вопрос, что есть первая величина «скорость загрузки файла»?
1. В начале скорость 0 и работает первый пункт.
2. Количество загруженных данных делённое а время.
То есть начинаем случайно, через какое-то время измеряем скорость и переключаемся напоследовательную загрузку? Но скорость последовательной загрузки будет скорее всего ниже случайной, можно ошибиться.
Если общая скорость загрузки станет меньше битрейта клиент опять вернётся к случайной загрузке.
Мне кажется, что более эффективна должна быть другая стратегия. Разбиваем файл на фрагменты по X минут (для этого нужно знать его битрейт). Каждый фрагмент загружаем случайно, затем воспроизводим. Пока смотрим — загружаем следующий. Если не успели — рекламная пауза.Если успеваем и есть свободные ресурсы сети (это нужно постоянно измерять) — параллельно загружаем случайные блоки.
Если я правильно понял то например получается:
  • Первый фрагмент загружен и мы его смотрим.
  • Второй в этот момент загружается но случайными частями.
  • Остальные фрагменты остаются пустыми.


Случайную загрузку нельзя ограничивать фрагментом поскольку единственный сид уйдет и все останутся с недогруженным файлом.
Пока человек смотрит фрагмент N, клиент скачивает фрагмент N+1.
Как только N+1 скачан, начинается полностью рандомная закачка, пока человек не перейдёт к просмотру N+1 (тогда с приоритетом качается N+2).

Случайную загрузку нельзя ограничивать фрагментом поскольку единственный сид уйдет и все останутся с недогруженным файлом.


Это намного лучше, чем режим «качать строго последовательно», который включают пользователи сейчас, чтобы «качать и смотреть».
Так у меня примерно также качается. Последовательно то что предположительно смотрит пользователь + некоторое время вперёд а далее все остальное случайно.

Бывает что у пира вообще нет частей для последовательной загрузки тогда выбирается случайная доступная часть.
В настройках по умолчанию на 20 секунд вперёд загрузка стоит значение Downloads.MediaBuffer
Второй в этот момент загружается но случайными частями.
Остальные фрагменты остаются пустыми.

Если есть свободная пропускная способность сети, то остальные тоже загружаются случайно. Как это измерять, нужно еще придумать.

Случайную загрузку нельзя ограничивать фрагментом поскольку единственный сид уйдет и все останутся с недогруженным файлом.

Если уйдет единственный сид, все останутся с носом при любом способе загрузки.

Пиры подключаются к раздаче в разное время (если только это не онлайн трансяция), за счет этого высока вероятность того, что фрагмент, который нужен мне прямо сейчас, есть уже у нескольких пиров. Точнее, отдельные блоки этого фрагмента. Не смотря на то, что сид пока еще один.
Возможно я ошибаюсь, но например qBittorrent качает случайными кусками, если скорость при последовательном проседает. Или я всё-таки ошибаюсь?
Запросто, он же работает на libtorrent, а там из коробки есть куча возможностей для всяких смешанных режимов.
Есть ещё такое соображение: клиент сам может сначала скачать заголовки и расчитать длительность медиафайла, а по ней — средний битрейт.
Да но для этого им надо знать кучу форматов видео и аудио файлов. А этот маленький параметр(br) позволяет этого избежать.
Можно третий вариант придумать: качаем последовательно и одновременно случайные блоки, с приоритетом первых блоков.
В том же utorrent выставляешь приоритет внутри конкретного торрента на файты: high normal low и получаем «пулю в лоб» а не приоритет. Часто приходится для следующих файлов выбрать skip и затем только после закачки первого файла уже поставить любой другой приоритет для файлов skip.
Подскажите, какое ПО использовать вместо Shareaza под MacOS?
Например sharelin.sourceforge.net/ если вам нужен доступ в Gnutella2 но битрейт пока что поддерживается только в обозначенной выше версией Shareaza. Правда я что то напортачил и параметр можно только в ручную задать в свойствах закачки. Исправляю.
На выходных начал делать опенсорсный клиент под мак с главной целью улучшить «смешанный» режим (в частности, поиграться с параметрами piece deadline и другими, которые есть в libtorrent). Наверно, надо будет прикрутить минимальный GUI и выложить на гитхаб.
А уже есть web-приложение, например во флеше, которое бы сочетало в себе плеер и качалку? Чтоб можно было на сайты устанавливать плеер, который только по бит-торенту выкачивал видео.
Год-два назад здесь пиарились ребята, которые делали такой браузерный плагин (не на флеше). Где они сейчас, не знаю.
Ну плагин это одно. А полноценный веб-плеер это другое.
Флеш — универсальный плагин, есть у очень многих владельцев браузеров, а те ребята предлагали узкоспециализированный плагин, и кроме плагина, там еще что-то надо было ставить. Т.е. распространенность ниже на порядки.
Мои мысли в слух, по мотивам p2p браузера, p2p плагина для браузера и просмотра/прослушивания видео во время загрузки p2p клиентом:

Фантазия называется «Расширение к обычному браузеру в виде пользовательского скрипта или некого другого расширения».

Принцип работы:
На обычной http странице выводится информация со специальными тегами которые не отображаются в обычной ситуации (без установки расширения). Но если пользователь поставит специальное расширение, все эти теги будут срабатывать при загрузке страницы. Например на месте картинки будут ссылки: одна магнет-ссылка (не показывается, а автоматически сразу отправляется в p2p клиент), и вторая ссылка на файл на компьютере. Например, p2p клиент загружает файлы браузера по пути D:\Download\, а расширение браузера периодически заглядывает в эту папку и смотрит появились ли загруженные файлы, которые после загрузки можно уже отобразить в браузере (например ссылка на картинку будет file:///C:/Download/image1.jpeg)
Или в начале страницы разместить одну магнет-ссылку на торрент или dcls файл, как папку со вложенными всеми картинками или другими элементами веб-страницы.
Таким образом не нужно будет ставить специальный p2p браузер, загрузка файлов будет идти вашим любимым p2p клиентом, любой файлообменной сети. Два варианта отображения и работы сайта как обычный и с элементами p2p (вкл/откл установленного в браузере расширения). А если запилить в расширение иконку видеоплеера, то можно вывести загружаемое видео из p2p в любом качестве и любом формате прямо на странице браузера (вот тут и пригодятся возможности Shareaza с правильной загрузкой видео). Что у нас получится при реализации этого чуда:
Можно замутить свои ютубы и онлайн кинотеатры без нагрузки на сервера. Даже постеры и скриншоты в виде хешей в магнет-ссылках можно позаимствовать с других более популярных сайтов работающих по такой же p2p схеме, при этом скорость и доступность файлов лишь увеличится…

Проблемы реализации «мечты» с p2p клиентами.
Необходим новый специальный параметр в магнет-ссылке, например &x.yz=tracker.local прочитав который p2p клиент первый раз выведет сообщение «Загружать каждый раз файлы автоматически с тегом tracker.local (например название сайта) ?» Нажав «да» клиент больше не будет выводить окошки предупреждений, а будет сразу ставить на загрузку файлы в магнете которых есть параметр &x.yz=tracker.local

Вторая проблема, этот дополнительный параметр &x.yz не должен показываться в чатах p2p клиентов. Типа скопировал такую магнет-ссылку в чат, а юзер нажал один-другой раз и не врубается почему у него p2p клиент не спрашивает качать или не качать, а сразу грузит.

Загрузка магнет-ссылок p2p клиентом.
Вариант с веб-сидом, но без обычных пиров. В случае последних utorrent/Bittorent теоретически может помочь не работающий параметр fl если заставить его работать. А с DC++ клиентами и dcls файлом что делать? Его можно загрузить только с другого DC клиента либо по http ссылке так же как торрент файл. С другими p2p программами и сетями дело скорее всего обстоит так же…

Может есть у кого-нибудь желание соорудить такой юзер-скриптик эксперимента ради?
Вебстраницы отображаемые с сервера не имеют доступ к файлам на диске. Это можно обойти сохранив страницу на диск.
у меня были похожие идеи. Последнее время думал как обьеденить торрент, файллист, и магнеты.
А можно ли тогда поступить таким образом:
Есть заглавная страница некого сайта ....ru/page1
На этой странице выводится кнопочка магнет-ссылки на папку с вложенными сохранёнными веб-страницами этого сайта (не всего, а лишь основной части его, ну скажем так штук 10 основных страниц ). По этим сохранённым веб-страницам пользователь сможет переходить на своём локальном диске, как например делают веб-мануалы некоторые производители железа.
Как бы решение:
1. На этих сохранённых страницах должны присутсвовать три ссылки в виде трёх кнопочек
а) Ссылка вида file:///D:/Download/page2.htm (переход на другую сохранённую на компьютере сраницу если такая есть)
б) Ссылка на страницу сайта ....ru/page2
в) Магнет-ссылка, пройдя по которой пользователь сохранит страницу page2 себе на комьютер, что бы потом мог просмотреть её оффлайн.
И тут возникает вопрос — зачем все эти мучения, если удобство пропадает? По факту получается не p2p браузер, а сёрфинг сугубо по своему компьютеру.

Рассмотрим другой вариант.
Опять же имеем теже 10 сохранённых страниц, но только без содержания внутри, а лишь оформление. Так как оформление страниц у сайта как правило одинаковое почти на всех страницах, то все эти 10 страниц перезагружаются с локального диска с добавлением отдельных элементов. Например, переходим со страницы меню тем page10 на страницу конкретной темы рage11, при этом с локального диска загружается скелет страницы «темы» page3, и каким-то образом (может плагином /скриптом каким-нибудь) в поле видимого контента страницы page3 будет вставляться с ....ru/рage11 весь текст и ссылки страницы рage11. Так как сами страницы будут находится на локальном диске, соответсвенно все ссылки на все локальны файлы (скриншоты, видео) уже можно будет размещать внутри кода htm страницы.

base64 смотрится со стороны прикольно, но как-то это больше похоже на попытку обойти проблемe обмена через p2p. То есть, если впихнуть base64 код картинок в те мои придуманные 10 страниц которые будут хранится у юзера всегда, то это в принципе нормально, а вот заменить им все остальные картинки — выглядет не очень (например скриншоты в большом разрешении и тяжеловесном формате).

Схему просмотра видео файлов по клику магнет-ссылки в расширениях mkv, avi и прочих, наверно возможно реализовать только в таком варианте www.youtube.com/watch?v=xHaS21rxpbs Браузер отправляет магнет-ссылку в p2p клиент и так же чуть позже посылает команду на открытие видео файла на компьютере (например плеером VLC), который к этому времени уже должен будет появиться в папке и начать загружаться.

ivan386, кстати раз уж вы являетесь разработчиком клиента, который работает и взаимодействует со всеми основными p2p протоколами, может быть вам будет интересно пообщаться с разработчиками флайлинка на их хабе dchub://dc.fly-server.ru они там очень часто бывают.
Sign up to leave a comment.

Articles