Такого функционала не хватало в емуле и торенте... Проще наверное модифицировать их чем раскручивать новой протокол и писать клиенты под него под все платформы.
Это не принципиально. Суть в том что всем файлобменым сетям (емул, торент, кааза, и мн д.р.) не хватает одного и того же функционала. То есть возможности определять одинаковые куски файлов таким образом увеличивая общее количество источников для каждого загрузки.
Ну поможет не поможет, это вопрос к теме разговора не имеет. Я всего лишь говорил что: "Такого функционала не хватало в емуле". Если конечно слово поможет вы употребляли в смысле "спасет" ;)
а между прочим-очень интересная новость!сам уже где-то год использую BitTorrent и сталкивался с такой проблемой(
а протокол может настолько схож с битторент,что и модифицировать существующие клиенты под него можно будет(мммда,врядли,конечно)Но!и данки и битторрент-начинались с интересной идеи ;))
Ну этого не так жалко. А вот поскольку служебный трафик увеличится, то могут запросто найтись ситуации, когда новая технология будет в проигрыше по скорости скачивания. И если такое будет происходить слишком часто, тогда особой радости в ней нет :)
жаль, что ориентировано на обмен публикациями, было бы лучше, если четко ориентировали на медиа
Файлы музыкальные(или видео) могут и не совпадать (один с vbr, другой - нет, или кодеки разные), а при этом содержимое практически идентично. Вот такой вариант, принимающий это во внимание, был бы, конечно, оптимален.
Не совсем верно. Их можно перекодировать _перед_ проведением сравнения, таким образом, перед тем как резать на куски и сравнивать, все файлы уже клиентом будут приведены в унифицированный вид - вот о чем я ратую, скорее.
Если вавы "похожи", то это уже означает, что у них почти нет ничего общего. Они будут похожи для нас и для статистического анализа, а с точки битов и байтов они будут совсем разные. Как будут при этом похожи друг на друга сжатые файлы и говорить не стоит.
Ерунда какая-то. Где они находят похожие фрагменты разных файлов? <html> в заголовках веб-страниц? FourCC в начале видео-файлов? Много на этом сэкономишь, да. Всё что можно, уже сжато компрессорами и кодеками, и передаётся в несжимаемом виде (= в уникальных кусках). Разве что ISO операционных систем могут содержать одинаковые части.
Рекомендую в качестве эксперимента взять два одинаковых видеопотока и:
а) смуксить их с разными аудидорожками в avi;
б) смуксить их с разными аудиодорожками в mkv;
в) смуксить их в mkv так, чтобы один из файлов включал также аудиодорожки другого.
Затем провести побайтовое сравнение результатов и ещё раз переосмыслить свою гипотезу.
Интересно, а считать он будет фрагменты строго от начала?
Ведь если на байт сдвинуть окно, которым вырезаются фрагменты, они будут совершенно не похожи по чексуммам.
Тут было бы лучше нечто статистическое, которые бы искало "похожие" фрагменты, а не идентичные. Хотя для определенного типа данных покатит наверное.
ну это уж сильно статистично :)
Для музыки такой подход(описанный в топике) вообще сомнителен мне кажется. Чуть изменить качество сжатия, и файл не похож совсем :)
А еще лучше, вообще не качать, а найти на локальном компе нужные куски и из них собрать то что надо. Я думаю только из папки Windows столько всего можно насобирать =)
а если из кода Windows, защищённого MSовским копирайтом, собрать песню Димы Билана - будет ли она, как derived work, защищена тем же копирайтом, что и код? ;)
Учёные создали улучшенную версию BitTorrent