Торренты содержат поблочные хеши, а не пофайловые.
При текущей реализации все файлы раздачи виртуально склеиваются в один массив байтов, этот массив разбивается на одинаковые по размеру блоки, хеши каждого блока пишутся в метафайл, в info/pieces. Выбор размера блока оставлен на усмотрение генератора метафайлов. info содержит имена файлов, размеры файлов, размер блока хеширования и pieces — те самые хеши каждого блока. Для идентификации торрентов используется хеш от info, поэтому BTIH, BitTorrent Info Hash. BTIH меняется при любом изменении info: перестановка файлов, переименование файлов, изменение размера блока хеширования. pieces внутри метафайла имеют смысл только для текущей раздачи. Для других раздач с совпадающими файлами установить факт идентичности файлов нет способа без пофайловых TTH.
Хешируемые блоки обычно не совпадают с границами файлов. Размер хешируемого блока произвольный, так что установить, принадлежит ли файл раздаче, можно только по косвенным признакам, сопоставляя размер файла и перебирая все места, куда бы этот файл мог подойти.
maggot является полной противоположностью гибкости упомянутых сетей
magnet есть нормальный (как в Shareaza и GreyLink), с dn, xl и хешами, специфичными для файлов, а не для раздачи.
А есть magnet ненормальный, плод продукта каких–то торренторазрабов, которые услышали звон, да не поняли, где он, не добавили пофайловый TTH в свои клиенты, не научились считать TTH директории, но тоже полезли в magnet URI.
Впрочем, magnet по стандарту помойка, в которой можно даже сослаться на результаты поиска в p2p по ключевым словам, так что рейдерство торренторазрабами magnet URI вписывается в общую картину.
Мне даже не вериться, что я когда-то верил, что у нас в стране что-то можно поменять. Хотя всего-то лет 5 прошло. Бил в себя в грудь и говорили «что я буду работать только в РФ», когда мне предлагали хорошую работу в штатах
Принципиальный вопрос не в том, где зарабатывать деньги, а где их тратить, если на то пошло.
Недостаток BTIH — зависимость от размера минимально проверяемого блока. Разные размеры блоков, разные имена файлов, разная метаинформация — всё это меняет BTIH. TTH для файла определён жёстко, но при этом в силу своей древесной структуры позволяет варьировать размер минимально проверяемого блока по степеням двойки, не изменяя корневой хеш. Размер зависит от того, какой слой Merkle Tree передаётся между пирами. У разных протоколов могут слегка отличаться требования к степени детализации, но в случае с TTH можно увеличивать детализацию на лету.
Gnutella2 умеет искать и по SHA1, и по MD5, и по TTH, и по ED2K. Если у Shareaza не хватает важных хешей, она пытается узнать их от других узлов сети (Shareaza хранит метаинформацию даже после удаления файлов), но этой информации она может верить только на слово (по принципу большинства)
А что толку от BTIH, если его каждый как хочет считает? BTIH как раз и старый. Надо было сделать proof of concept p2p, а какие через десять лет проблемы возникнут, было видно лишь смутно. В то время какое–то оправдание было, сейчас оправдания нет. RetroShare, maggot, Shareman, каждый со своими велосипедными хешами. Так нельзя.
Причина, по которой предпочтение отдаётся TTH — его технические особенности и его использование в двух независимых p2p протоколах. Собственно, в DC++ TTH появился как раз из–за того, что кто–то из разработчиков оценил TTH по достоинству. До этого NMDC был как FTP с поиском. Если копаться в старых клиентах, в каком–то консольном клиенте NMDC можно найти поддержку ED2K, то есть, такой однозначный выбор был хеша сделан не сразу.
Насчёт emule не знаю, но ED2K всяко полезней считать, чем MD5. Насколько я помню, Gnutella2 позволяет искать по ED2K
По-моему большинство уже давно в торрентах
Если в клиентах BitTorrent появится поддержка списка файлов, пофайловый TTH и поиск по TTH, я не против BitTorrent.
Пока этого нет, всё это большинство пусть сидит в торрентах хоть до посинения, количество не перейдёт в качество. Прогресс для пользователей этого протокола заблокирован.
И, насколько я помню, некоторые сайты предлагают использовать собственные даунлодеры, и почему бы не Shareaza? Shareaza умеет работать HTTP качалкой и встраиваться в браузер как FlashGet. При этом через расширения HTTP можно получить хеши. В общем, если у юзера чего–то не стоит, я бы не сказал, что это большая проблема.
Унификацию хешей я считаю прогрессом. Многие хорошие вещи не случились потому что Яндекс.Диск пишет один хеш, open source дистрибутивы для проверки целостности пишут в checksum.sfv другой хеш, а среди p2p–клиентописатели слишком велики доли двух групп: первая группа по наивности использует цельнофайловый хеш, приглашая тем самым недоброжелателей безнаказанно отравлять раздачи, как это было в Gnutella1 до введения TTH. Вторая группа учитывает эту проблему, но как решение, велосипедит пи–хеши и BTIHи. Вместо того, чтобы всем дружно использовать TTH.
Да, и DC, похоже, в России потихоньку региональные провайдеры прикрывают
DC есть и глобальные. DC вообще не в России зародился. Начиная со StrongDC++, есть DHT, хотя децентрализация пока не столь развита, как в Gnutella2. Как постоянный пользователь GreyLink, я могу сказать, что достойных альтернатив DC++ и Gnutella2 пока не состоялось. Чтобы они быстрее состоялись, хорошо бы, чтобы все использовали TTH. Даже там, где это не критично. Пусть программисты задумываются, а почему из всех хешей выбран именно TTH, обнаруживают, что, оказывается, без унификации хешей к TTH столько прогресса прошло стороной, запоминают и, может быть, на несколько велосипедов станет меньше, а прогресс станет ближе
Чтобы не устраивать Вавилонское столпотворение. Не для целостности, так для информации TTH крайне желательно, чтобы был, а если в виде магнитной ссылки — ещё лучше. А если HTTP сервер будет поддерживать расширения HTTP, которые позволяют Shareaza находить альтернативные источники в p2p сетях — вообще замечательно. Это поспособствует тому, чтобы эти расширения HTTP появились в других p2p–клиентах.
Маркет устроен так, что в него практически невозможно попасть приложениям, не написанным на выбранных неизменно дурным вкусом Microsoft языках программирования. Выделение динамической памяти — запрещённый вызов, и те приложения, которые всё же прошли в маркет, прошли только по той причине, что память выделяется не напрямую через WinAPI, а через run-time DLL этого языка программирования.
Можно догадаться, run-time DLL каких языков программирования доступны в Windows 8. Разумеется, ничего хорошего:
Yes. We are very keen on supporting WinRT with native Delphi & C++ code. Right now, the issues surrounding the WinRT space center around the fact that many OS-supplied APIs which are required by anyone implementing their own language RTL are actually off-limits unless you're the VC++ RTL DLL. You know, little things like RtlUnwind for exception processing and VirtualAlloc (et. al.) for memory management… Any calls to those APIs from your application will automatically disqualify your application from being an «official» WinRT application capable of delivering through the MS app store.
Right now the VC++ RTL DLL is given special dispensation since that is the library that makes the calls to those forbidden APIs and not directly from the user's app.
If you have to be locked down to MS tools to develop targeting WinRT, then MS is shooting itself in the foot. Windows history of commercial success is not due MS, but due to the huge number of Windows applications, created by a vast number of tools and compilers out there, both commercial and free/open sorce.
Поддерживаю назревающий тренд «берите wine и делайте апгрейд до Linux вместо Windows 8».
Вот ещё бы студия поддерживала этот тренд. Wine — потому что есть ещё Solaris, BSD, Mac OS, и кроме Wine сложно найти лучший нативный аналог Java.
При текущей реализации все файлы раздачи виртуально склеиваются в один массив байтов, этот массив разбивается на одинаковые по размеру блоки, хеши каждого блока пишутся в метафайл, в info/pieces. Выбор размера блока оставлен на усмотрение генератора метафайлов. info содержит имена файлов, размеры файлов, размер блока хеширования и pieces — те самые хеши каждого блока. Для идентификации торрентов используется хеш от info, поэтому BTIH, BitTorrent Info Hash. BTIH меняется при любом изменении info: перестановка файлов, переименование файлов, изменение размера блока хеширования. pieces внутри метафайла имеют смысл только для текущей раздачи. Для других раздач с совпадающими файлами установить факт идентичности файлов нет способа без пофайловых TTH.
Хешируемые блоки обычно не совпадают с границами файлов. Размер хешируемого блока произвольный, так что установить, принадлежит ли файл раздаче, можно только по косвенным признакам, сопоставляя размер файла и перебирая все места, куда бы этот файл мог подойти.
Я когда–то писал про TTH в BT на форуме uTorrent. Не нашли мои мысли тогда понимания. А проблема как была, так и никуда и не уйдёт.
magnet есть нормальный (как в Shareaza и GreyLink), с dn, xl и хешами, специфичными для файлов, а не для раздачи.
А есть magnet ненормальный, плод продукта каких–то торренторазрабов, которые услышали звон, да не поняли, где он, не добавили пофайловый TTH в свои клиенты, не научились считать TTH директории, но тоже полезли в magnet URI.
Впрочем, magnet по стандарту помойка, в которой можно даже сослаться на результаты поиска в p2p по ключевым словам, так что рейдерство торренторазрабами magnet URI вписывается в общую картину.
Принципиальный вопрос не в том, где зарабатывать деньги, а где их тратить, если на то пошло.
Когда AES-NI станет достаточно устаревшей технологией, чтобы у большинства она появилась, вот это будет интереснее жить.
Amahi для домашнего медиа–, файл–, вики– и т. п. сервера
ClearOS для сервера и шлюза в Интернет предприятия
Project Byzantium для роутера–участника ячеистой сети
Недостаток BTIH — зависимость от размера минимально проверяемого блока. Разные размеры блоков, разные имена файлов, разная метаинформация — всё это меняет BTIH. TTH для файла определён жёстко, но при этом в силу своей древесной структуры позволяет варьировать размер минимально проверяемого блока по степеням двойки, не изменяя корневой хеш. Размер зависит от того, какой слой Merkle Tree передаётся между пирами. У разных протоколов могут слегка отличаться требования к степени детализации, но в случае с TTH можно увеличивать детализацию на лету.
Gnutella2 умеет искать и по SHA1, и по MD5, и по TTH, и по ED2K. Если у Shareaza не хватает важных хешей, она пытается узнать их от других узлов сети (Shareaza хранит метаинформацию даже после удаления файлов), но этой информации она может верить только на слово (по принципу большинства)
Причина, по которой предпочтение отдаётся TTH — его технические особенности и его использование в двух независимых p2p протоколах. Собственно, в DC++ TTH появился как раз из–за того, что кто–то из разработчиков оценил TTH по достоинству. До этого NMDC был как FTP с поиском. Если копаться в старых клиентах, в каком–то консольном клиенте NMDC можно найти поддержку ED2K, то есть, такой однозначный выбор был хеша сделан не сразу.
Насчёт emule не знаю, но ED2K всяко полезней считать, чем MD5. Насколько я помню, Gnutella2 позволяет искать по ED2K
Если в клиентах BitTorrent появится поддержка списка файлов, пофайловый TTH и поиск по TTH, я не против BitTorrent.
Пока этого нет, всё это большинство пусть сидит в торрентах хоть до посинения, количество не перейдёт в качество. Прогресс для пользователей этого протокола заблокирован.
И, насколько я помню, некоторые сайты предлагают использовать собственные даунлодеры, и почему бы не Shareaza? Shareaza умеет работать HTTP качалкой и встраиваться в браузер как FlashGet. При этом через расширения HTTP можно получить хеши. В общем, если у юзера чего–то не стоит, я бы не сказал, что это большая проблема.
Унификацию хешей я считаю прогрессом. Многие хорошие вещи не случились потому что Яндекс.Диск пишет один хеш, open source дистрибутивы для проверки целостности пишут в checksum.sfv другой хеш, а среди p2p–клиентописатели слишком велики доли двух групп: первая группа по наивности использует цельнофайловый хеш, приглашая тем самым недоброжелателей безнаказанно отравлять раздачи, как это было в Gnutella1 до введения TTH. Вторая группа учитывает эту проблему, но как решение, велосипедит пи–хеши и BTIHи. Вместо того, чтобы всем дружно использовать TTH.
DC есть и глобальные. DC вообще не в России зародился. Начиная со StrongDC++, есть DHT, хотя децентрализация пока не столь развита, как в Gnutella2. Как постоянный пользователь GreyLink, я могу сказать, что достойных альтернатив DC++ и Gnutella2 пока не состоялось. Чтобы они быстрее состоялись, хорошо бы, чтобы все использовали TTH. Даже там, где это не критично. Пусть программисты задумываются, а почему из всех хешей выбран именно TTH, обнаруживают, что, оказывается, без унификации хешей к TTH столько прогресса прошло стороной, запоминают и, может быть, на несколько велосипедов станет меньше, а прогресс станет ближе
Чтобы не устраивать Вавилонское столпотворение. Не для целостности, так для информации TTH крайне желательно, чтобы был, а если в виде магнитной ссылки — ещё лучше. А если HTTP сервер будет поддерживать расширения HTTP, которые позволяют Shareaza находить альтернативные источники в p2p сетях — вообще замечательно. Это поспособствует тому, чтобы эти расширения HTTP появились в других p2p–клиентах.
Ещё одна слабо документированная фича Delphi pre-2010 — это RTTI, который включает в себя published свойства, поля и методы, посредством которой можно сделать AsDynamic в том числе и на старых версиях Delphi
По поводу оверхеда — да, это действительно так. Смысл статьи — показать, что кое–какие фичи в Delphi реализуемы и показать, куда копать
Кстати, System.Rtti.TValue — это как раз интерфейс в записи
Маркет устроен так, что в него практически невозможно попасть приложениям, не написанным на выбранных неизменно дурным вкусом Microsoft языках программирования. Выделение динамической памяти — запрещённый вызов, и те приложения, которые всё же прошли в маркет, прошли только по той причине, что память выделяется не напрямую через WinAPI, а через run-time DLL этого языка программирования.
Можно догадаться, run-time DLL каких языков программирования доступны в Windows 8. Разумеется, ничего хорошего:
Is there any indication that Embarcadero wants to support native Metro development using the unmanaged API?
Поддерживаю назревающий тренд «берите wine и делайте апгрейд до Linux вместо Windows 8».
Вот ещё бы студия поддерживала этот тренд. Wine — потому что есть ещё Solaris, BSD, Mac OS, и кроме Wine сложно найти лучший нативный аналог Java.