Подробности.
Описание интерфейса и настроек Мула закончено и теперь пора перейти к теории функционирования самой сети. Может показаться, что это уже ненужное углубление в детали, однако, понимание механизмов eD2k и Kad сильно упрощает работу с P2P.
Когда я сам только поставил Мула, меня больше всего интересовали вопросы рейтинга (где его посмотреть? где посмотреть чужой рейтинг? по каким критериам их сравнивать?), а так же вопросы разрыва соединения (останутся ли мои очки закачек после отключения от сети? останусь ли я в очереди или придётся жать эти тысячи позиций и дальше?). С этих вопросов я и начну.
При первом же запуске eMule генерирует User Hash - уникальный идентификатор пользователя, по которому другие клиенты в дальнейшем cмогут вас узнавать. После выхода на некоторое время из сети, даже если поменяется IP-адрес, при установлении соединения с другим клиентом, ваш Мул будет отправлять свой User Hash, и по нему клиент вас "вспомнит". Про каждого известного пользователя eMule хранит информацию в своих файлах. Перегружать описание конкретными файлами мне сейчас не хочется - полный список используемых файлов я помещу в конце статьи в Приложении I.
Такого понятия как "Рейтинг" в глобальном понимании не существует, и посмотреть его, соответственно, нельзя. eMule считает рейтинг всех пользователей, которые что-то отдали вам или взяли у вас, независимо от других клиентов. Если я отдал клиенту "A" 10 мегабайт, то мой рейтинг для него будет достаточно высок. В то же время я могу иметь низкий рейтинг у клиента "B", которому я не отдал ничего. Как именно считается рейтинг, зависит исключительно от реализации клиента (где-то такой системы вообще нет) и его настроек. Что касается настроек, то в eMule их всего две: либо рейтинги используются, либо нет.
В последних версиях система такая: вначале вычисляется "соотношение" (это кривой русский перевод, в оригинале это звучит как "модификатор"). Для его получения вначале вычисляют два рейтинга:
R1 = ( Upload * 2 ) / Download
R2 = SQRT ( Upload + 2 )
Здесь Upload - это сколько пользователь отдал информации (в мегабайтах), Download - сколько скачал сам (в мегабайтах), SQRT - корень квадратный. В качестве модификатора выбирается наименьшая из этих двух оценок, округлённая до десятых по правилам арифметики. Здесь есть ряд НО:
1). Если в общей сложности было закачано меньше 1 Мб, модификатор устанавливается в единицу.
2). Если пользователь ещё ничего сам не скачивал, модификатор устанавливается в десятку.
3). Если пользователь ещё ничего не качал и не закачивал, модификатор устанавливается всё равно как 1.
4). Максимальное значение модификатора - 10. Минимальное - 1. Если полученные значения выходят за эти диапазоны, то они понижаются/повышаются до единицы/десяти соответственно.
С помощью модификатора вычисляется непосредственно Рейтинг. Изначально он равен 100, умноженный на модификатор и, если пользователь не поддерживает расширенный протокол eMule, делит Рейтинг пополам. Если в окне "файлы обмена" вы устанавливаете файлам приоритеты, то если он запросил файл, приоритет которого низкий/высокий, то и рейтинг его соответственно тоже понижается/повышается. Множители, на которые умножается рейтинг в зависимости от приоритета, такие: 0.2, 0.6, 0.7, 0.9 и 1.8 для "очень низкого", "низкого", "нормального", "высокого" и "очень высокого" соответственно. В ранних версиях эти множители отличаются (вообще в предыдущих версиях eMule рейтинг вычислялся несколько по другим правилам, но таких клиентов сейчас пренебрежимо мало).
Как только пользователь запрашивает у вас какой-либо файл, для него начинают считаться Очки по формуле:
Очки = ( Рейтинг * время_в_очереди_в_сек ) / 100
Порядок, кто в каком будет у вас скачивать, определяется количеством очков - у кого их больше, тот и качает. Естественно, что тот, у кого выше Рейтинг, будет набирать очки быстрее и продвигаться по очереди соответственно тоже быстрее. Само QR показывает положение пользователя в очереди исходя из распределения Очков, и в вычислениях никакого участия не принимает.
Существенный момент, который относится к основным вопросам, которые я оговорил в начале. После получения значения QR от клиента, ваш Мул разрывает с ним соединение - оно не нужно. Как только ваша очередь подходит, сам клиент отправляет вам запрос на закачку. Если вы разорвали соединение и потом вернулись снова, то ваш Мул опять посылает запрос источнику и, даже если у вас сменился IP, источник узнаёт вас по вашему хэшу и сообщает вашу позицию в очереди. Ничего никуда не пропадает (только если свою очередь вы не пропустили).
Теперь пару слов о сетях. Сами закачки идут непосредственно с чужих компьютеров и сеть, которая используется, тут не причём - она нужна только для поиска. eD2k основана на серверной моделе. Есть ряд серверов, подсоединяться можно к любому. После подсоединения сервер выдаёт пользователю ID (назначение которого - различать High и Low; так же ID хранит в себе IP-адрес, формулу генерации ID я приводил выше).
При подключении к eD2k-серверу, eMule отправляет ему информацию о своих расшаренных файлах. Сервер заносит пользователя и его файлы в свою базу источников. Теперь при поиске, если кто-то ищет файл с именем, которое имеется у вас, он выведет вас как источник и отправит страждущему ваш IP-адрес. На этом роль eD2k заканчивается.
Иная ситуация с Kad. В Kademli'и каждый клиент сам по себе является сервером. Какого-либо "главного" сервера не существует - все равны. Для подключения к сети надо знать хотя бы одного клиента, который имеет подключение. Он в свою очередь передаёт адреса других клиентов, те третьих и пошло-поехало. Каждому клиенту (он же сервер) присваивается ID. В этом случае ID это уже не просто число - оно содержит в себе информацию о том, списком источников на какие файлы в основном располагает данный пользователь. Если человек собирает видеоклипы, очевидно, его ID будет содержать информацию о том, что клипы лучше всего искать через него. Углубляться в математические алгоритмы, которые это всё реализуют я не буду, по крайней мере в этой статье.
При получении списка KAD-серверов учитывается иерархия, называемая в eMule дистанцией. Естественно, что отправить запрос на поиск по тысяче адресов как минимум неэкономно, поэтому запрос отправляется только на "ближайшие" сервера, которые в свою очередь отправляют запросы на ближайшие для них и так далее и так далее. При этом учитывается скорость соединения, основная тематика источника и прочее - это материал отдельной статьи, не меньшей по объему, чем эта.
В любом случае назначение сети Kademlia, так же, как и eD2k, исключительно в поиске источников. Отличие Kad в том, что для её функционирования не требуется серверов, но недостатка в последних пока не наблюдается. Если через сеть Kad кто-то ищет что-то у вас, то у вас это отобразится в окне Kad в таблице "поиски в данный момент". Делать с ними ничего нельзя.
Если посмотреть на странице "передачи" в графу "размер" для источников, то там можно увидеть одну из четырёх надписей для каждого клиента: eD2k server, Kad, "обмен" или "пассивный". Надпись указывает на способ, которым был найден этот источник. С Kad и eD2k и так всё понятно; обмен означает, что вы узнали про этот источник в результате опроса других источников, "пассивный" - источник сам к вам постучался за каким-то файлом, и у него оказалась требуемая часть.
После получения списка источников от сервера или из Kad, идёт опрос каждого из них на наличие ещё неизвестных источников (это в случае если закачка запущена). От новых источников вы получаете новые списки и так продолжается, пока источники не "иссякнут". Подключение к какой-либо из сетей при этом не обязательно - можно вообще отрубить eD2k и Kad - закачек это не остановит, и новые источники по-прежнему будут искаться.
Следующий важный момент - это хэш. Каждый файл разбивается Мулом (и другими клиентами - это стандарт eD2k и Kad) на блоки по 9.28 Мб. От каждого блока вычисляется хэш-функция по алгоритму MD4. Когда хэши каждого блока подсчитаны, от всех хешей вместе взятых вычисляется опять же MD4-хэш, который в совокупности с размером и является идентификатором файла. Ссылки на ed2k файлы выглядят следующим образом:
ed2k://|file|name|size|fh|/
С установленным Мулом браузер может обрабатывать такие ссылки так же как и обыкновенные. Здесь file - ключевое слово, обозначающее то, что это именно файл, а не что-то другое (аналогичные ссылки бывают для серверов, источников, списков серверов и пр.), name - имя файла как есть, size - размер файла в байтах, fh - хэш файла. Сам хэш файла официально (в оригинале) называется "File Hash", хэши для конкретных блоков "Part Hashes". Эти самые Part Hashes можно добавлять в ed2k ссылку:
ed2k://|file|name|size|fh|p=ph_1:ph_2:...:ph_n|/
Part Hashes отделяются друг от друга двоеточиями. Полный набор Part Hashes называется Hashset (в ссылках можно указывать только полный Hashset, указание только отдельных Part Hashes не допускается).
В то время как File Hash является идентификатором файла, по которому происходит поиск, Part Hashes необходим за контролем над ошибками. Этот механизм называется ICH (Intelligent Corruption Handling - Интеллектуальная Обработка Ошибок). После полного скачивания каждого блока, eMule вычисляет его Part Hash и сопоставляет с оригиналом. Если они сходятся - всё скачано правильно. В противном случае произошла ошибка, и скачивание блока начинается заново. Алгоритм ICH заключается в том, что скачивается не весь блок, а последовательные маленькие кусочки по 180 Кб. После каждого такого куска Part Hash проверяется заново и, если ошибка произошла при передаче начального фрагмента блока, то в случае совпадения хэшей дальнейшее скачивание не требуется. Если ошибка произошла в конце блока, то ICH мало чем поможет. Таким образом, ICH в среднем ускоряет повторную закачку повреждённых блоков на 50%.
Начиная с версии eMule v.44a вводится ещё один механизм - AICH (Advanced ICH). Это придумка разработчиков eMule, но постепенно этот алгоритм начинают поддерживать и все остальные клиенты. Идея полностью аналогична обычному хэшу, но только есть два отличия: используется не MD4, а SHA-1 и вычисляется функция не сразу от целых блоков, а от маленьких кусков по 180 Кб. При скачивании файла его целостность (отсутствие повреждений) дополнительно проверяется с помощью AICH.
В обычном ICH, как я уже говорил, идёт последовательное скачивание 180 Кб кусков, пока полученный хэш не будет соответствовать действительности. В случае с AICH этого не требуется - скачиваются только маленькие AICH-хэши для 180-килобайтных кусков и таким способом идёт поиск куска, при передаче которого произошла ошибка. Естественно, что такой способ быстрее. При начале закачки передаётся только полный AICH для всего файла, если же происходит сбой, то AICH для каждого куска отдельно запрашивается у источников. Ссылки с AICH выглядят так:
ed2k://|file|name|size|fh|h=aich|/
где AICH - непосредственно AICH-хэш. Его можно комбинировать с Hashset - тогда они разделяются с помощью "|".
Стоит сделать ещё один комментарий о сохранении своего хэша пользователя. Как уже писал, при первом запуске eMule присваивает пользователю свой хэш, по которому его определяют другие клиенты. В случае, если надо переставить Мула, перенести на другой компьютер и в других подобных случаях, когда без перестановки Мула не обойтись, нужно знать, где эти хэши хранятся. Здесь всё просто: это файлы preferences.dat и cryptkey.dat, которые хранятся в поддиректории Мула "config". Для переноса своего хэша на другого Мула достаточно перенести эти файлы. На этом обзор механизмов eMule можно считать законченным.
Оптимизация
Вот и дошли до того, ради чего, собственно, статья и затевалась. Говорить много о настройках не буду - все важные аспекты я уже выделил в соответствующем разделе "непосредственно описания". Отдельно остановлюсь только на лимитах скорости. Обычная рекомендация - отдавать под еМул много, но не всё. В этом, конечно, есть доля правды, однако только доля. Как в основном пишут, если отдать все ресурсы сети еМулу, то ничего не останется на другие приложения вроде того же интернет-браузера. В действительности, использовать ВСЕ ресурсы Мулу не даст операционная система - какой бы приоритет мы не поставили, как только тому же Эксплореру или качалке потребуется сеть, сам Windows урежет доступ еМулу, отдав часть другим приложениям - за это можно не беспокоиться.
Однако выставлять максимум всё же не стоит. Дело в том, что лимит на самом деле выставляется не жёстко и Мул всегда может незначительно выходить за пределы дозволенного настройкой. В то же время лимит используется как показатель того, с какой скоростью надо вести именно закачку/скачивание - обычные запросы хотя бы для обмена источниками здесь не учитываются. Если же закачка идёт на максимуме (что чаще всего и бывает), а лимит не установлен, то для таких важных вещей, как, например, опрос источников или установление соединения для скачивания, ресурсов может не хватить - Windows в этом случае уже не поможет, так как заботится он только о конкретных программах, не разбираясь, как они используют сетевые ресурсы внутри себя.
По этой причине, если лимит всё же установить, то при необходимости Мул выйдет за ограничения и нормально пошлёт запрос. В противном случае, весь канал будет забит закачкой, и запрос с большой степенью вероятности не пройдёт. То же самое касается и лимита на скачивание, однако если учесть, что скачивание в основном никогда не идёт на максимуме, лимит на даунлоад можно не ставить. Итого: настройка даунлоада - безлимитно, аплоада - лимит максимально большой, оставляя только 1-2 Кб/сек для нужд общения с другими источниками.
Второй важный момент, касающийся оптимизации - это расшаривание. Допустим, что вы поклонник группы Rammstein, однако совершенно случайно у вас оказался альбом группы "Стрелки", которых вы не перевариваете (я сказал для примера, мне вот клипы их очень нравятся, например :-)). Логично, что и качать вы будете в основном тяжёлый металл, может быть рок, панк, гранж. Нужно ли выкладывать для общего доступа "Стрелок"?
Вспомним о том, что рейтинг ведётся на компьютере каждого пользователя независимо. Вот у вас люди накачают "Стрелок", ваш рейтинг у них будет очень высоким, скачивание от них будет проходить на ура. А оно вам надо, с учётом того, что это пользователи, которые явно отличаются во вкусах с вами? Вряд ли у них окажется именно то, что требуется вам. Зато среди любителей Rammstein у вас рейтинга как раз таки из-за этих "Стрелок" и не будет. Вывод: расшаривайте только то, что вам самим интересно и то, подобное чему вы собираетесь выкачивать.
Так же важно, что расшаривать очень много файлов нежелательно - это приведёт к тому, что у вас очень сильно разрастётся очередь, вы всем будете отдавать понемногу, вследствие чего и рейтинг будет расти медленно, однако все эти пользователи будут, стоя в очереди, регулярно слать вам запросы и интересоваться положением дел в очереди да и обмениваться источниками. Только на этом потеряете. Однако самое важное в вопросах оптимизации, это...
Дружба. Друг, в понимании eMule, это пользователь, который находится у вас в списке в окне "Сообщения" и вы всегда знаете в online он или нет. Так же всегда можно послать ему сообщение - очень похоже на контакт-лист в аське. Что бы добавить человека в список друзей надо нажать на нём на странице "передачи" правой кнопкой и выбрать "добавить в друзья". Никакого подтверждения с его стороны не требуется - ему даже можно не сообщать, что он ваш друг. Так же друзей можно добавлять непосредственно по IP-адресу с портом (если знаете), а так же в IRC (там оно, правда, как-то криво реализовано).
Для друзей существует полезная вещь, называемая "дружественный слот". Он выставляется правым кликом на друге в окне "сообщения" - там будет одноимённый пункт. Дружественный слот можно выставлять только один. Человек, для которого стоит эта опция, всегда находится в вашей очереди в самом начале и, соответственно, всегда, когда ему что-то надо от вас, в очереди ему стоять не приходится. При этом количество того, что он у вас скачал, не считается.
Как я уже сказал, вашему другу можно даже не говорить, что вы его сделали своим другом. Так же не обязательно ему сообщать про дружественный слот - его eMule сам об этом не узнает. Вот вы сделали человека своим другом, выделили ему слот, и что получается - он непрерывно у вас что-то качает, но причин, по которым он так качает, ему не известно. Следовательно, в его Муле во всё это время сильно растёт ваш рейтинг. Таким образом, вы можете сами выбирать, с кем хотите меняться. Узнать, требуется ли ему что-то от вас или нет, можно, просмотрев очередь на странице "передачи". Так же, если у вас есть какой-то кусок файла, которого нет у него, а у него есть то, что требуется вам, однозначно его нужно делать вашим другом. К сожалению, такой способ пройдёт не всегда - у кого-то может быть отключена система рейтингов, кто-то может докачать нужный кусок и убрать файл, однако в большинстве случаев это срабатывает.
Теперь отвлечёмся от доунлоада и поговорим о предпросмотре. В самом Муле это реализовано откровенно отвратно. Для того, что бы была доступна опция "предпросмотр" необходимо скачать первый и последний блоки файла, что вообще-то не соответствует нормальным представлениям о формате видеофайлов. Даже без начальной части часто можно просмотреть то что скачалось. Все файлы, которые качаются Мулом в данный момент, лежат в поддиректории Мула "temp". Там лежит множество файлов. Сами качающиеся файлы имеют имя xxx.part, где xxx - некоторое число. Просто открываем файл любым проигрывателем и смотрим. Что там себе думает по этому поводу Мул совершенно не важно. Посмотреть, какой из файлов xxx.part соответствует какой закачке, можно в файле downloads.txt в директории Мула.
Официальная рекомендация от разработчиков eMule - использовать для предпросмотра программу "VideoLAN Client", однако эта рекомендация мне не понятна. Советую использовать "Media Player Classic 6" - он максимально прост, быстр и компактен, однако за счёт отсутствия наворотов с такими неполными файлами работает намного лучше всех остальных клиентов. К тому же он входит в пакет "K-Lite Codec Pack" - его так же необходимо установить для нормального просмотра видео любых форматов. Хотя, здесь уже, конечно, дело вкуса.
Последнее и немаловажное, что стоило бы отметить, это управление ЗДФ (запросами на другие файлы). Вещь простая, но очень важная. Для того, что бы получить возможность управлять ЗДФ, необходимо включить в настройках расширенный контроль (я это рекомендовал в соответствующем разделе). Само управление на самом деле сводится только к возможности установить на файл атрибут "Автосброс всех источников (ЗДФ) на этот файл" (надо правой кнопкой нажать на закачку и зайти в раздел "управление источниками (ЗДФ)" - в том меню будет только одна опция). При установке данного флажка, все источники, у которых уже запрошен другой файл, будут переноситься на этот. Об этой опции полезно помнить, когда скачиваешь несколько подряд идущих файлов (например, несколько частей фильма) и что бы с одной стороны не скачивать фильмы по отдельности, а с другой, что бы источники не конфликтовали друг с другом, полезно установить такой автосброс на первую часть (или на самую младшую из тех, что ещё не скачались).
Так же при расширенном управлении будет доступна опция "скачать части для предпросмотра". По причинам, указанным выше, использовать её не стоит. Просмотреть файл можно и без этих частей, а вот если указать скачивание конкретных фрагментов, то это здорово тормознёт даунлауд. Мул всегда для скачивания выбирает те части, которые наименее распространены - вполне логичный ход. Если же затребовать именно первую и последнюю части (на которые чаще всего самое большое количество источников) - то это только замедлит даунлауд, т. к. ваши части для предпросмотра мало кому нужны и качать их никто не станет - рейтинг это не сильно поднимет.
Обман
А вот и самое интересное. Начну, как водится, с теории.
Сам Мул имеет в себе встроенную защиту от возможного обмана - я не раз её уже упоминал; прежде всего это защищённый метод аутентификации.
При обычной аутентификации (то есть процессе, когда другой пользователь "узнаёт" вас) передаётся ваш хэш и всё. Однако никто вам не мешает и чужой хэш передать. При защищённом же методе - при передаче используется алгоритм шифрования RSA на 384х-битном ключе. Такой ключ не является надёжным (сейчас рекомендуемая длина ключа 2048 бит), однако этого чаще всего вполне достаточно - если иногда и появляется интерес покачать от имени другого человека с крупным рейтингом, то он в основном ограничивается одной закачкой. Пока будете ломать 384 бита, всё уже успеет докачаться по-честному. И хотя подделать чужой хэш даже без защиты не так уж и просто (а даже если его и подделают - это мало чем грозит, да и сложно предугадать у кого какой рейтинг - неясно кого ломать), отключать безопасную аутентификацию не стоит хотя бы по той причине, что это сейчас очень активно продвигаемая "фича" и вполне возможно, что так же, как пользователям без поддержки расширенного протокола eMule занижают рейтинг, в ближайших версиях рейтинг будут занижать и тем, у кого нет надёжной аутентификации. ВАЖНО!!! Если вы однажды использовали Мула с аутентификацией, то после, если аутентификацию вы отключите, ваши данные потеряются, т. к. остальные пользователи не будут знать, что вы отрубили защиту и по-прежнему будут требовать с вас цифровую подпись.
Переходим от теории к практике. В Инете есть множество "подправленных" Мулов, которые, якобы, ускоряют скачивание. Здесь надо опять ненадолго углубиться в архитектуру Мула. Регулярно eMule отправляет запросы пользователям, у которых вы что-либо качаете на предмет спросить место в очереди, обменяться источниками т. п. Такие запросы он шлёт каждые десять минут одному случайному пользователю из списка источников (для каждого из файлов). Если для файла в общей сложности менее сорока источников, то каждые десять минут запросы он шлёт каждому пользователю, с которым идёт обмен этим файлом.
Многие клиенты устроены таким образом, что чем чаще ты шлёшь запросы, тем быстрее продвигаешься в очереди. Все "подправленные" Мулы действуют именно по такой схеме. Однако сам Мул частые запросы не считает поводом для продвижения по очереди, а даже напротив. На странице "передачи" в самом низу в скобках около числа клиентов в очереди указано, сколько клиентов Мул забанил. Бан - это фактически игнорирование клиента, после бана он вообще теряет возможность что-либо у вас скачивать. Банит он как раз тех, кто шлёт запросы чаще, чем раз в десять минут, поэтому все эти "модификации" максимум что могут, это повредить.
Так же Мул банит пользователей, у которых он просто обнаруживает какое-либо несоответствие со стандартным протоколом. Он справедливо рассуждает, что раз протокол не стандартный, то это очередная "модификация", и даже если она не является жульнической, изменения в протоколе говорят о том, что она возможно малоэффективна и может содержать ошибки. Вывод: использовать только официальные версии eMule. Кстати, если хочется очень часто слать запросы, то скачивать "модификацию" совсем не обязательно - достаточно постоянно ставить закачку на паузу и снимать её - после каждой паузы Мул отправляет запросы сразу всем источникам.
Можно привести ещё один малоэффективный, не являющийся откровенно нечестным, но тем не менее нехороший способ улучшить своё положение в Муле. Как я уже писал, сеть Kad нужна только для поиска. Но, когда вы соединены с Kad'ом, то поиск ведётся так же по вашему компьютеру, что несколько забивает канал. Вывод - Kad можно отключить. Хотя такие советы можно встретить в сети, многого вы от этого не выиграете, а кто-то что-то не сможет найти. Не советую так поступать чисто по этическим соображениям.
Последний способ - единственный работающий и эффективный. Дело в том, что данные передаются не в том виде в каком они есть, а в сжатом. Например, нам надо передать строку "12312312312312345". Вместо того, что бы передавать её как есть, мы можем передать "(123)x(5)45" - получилось намного короче. В действительности используются другие способы сжатия, но про них я рассказывать не буду. Пример привёл исключительно с целью объяснить принцип людям, мало разбирающимся в компьютерных технологиях.
Чем больше в данных можно выявить подобных зависимостей, тем сильнее файл можно ужать (заархивировать). Опять же обращу внимание, что я привёл только самую примитивную зависимость в примере. Допустим, что мы передаём файл размером гигабайт, но он весь от и до состоит только из одних нулей - передастся по сети он за считанные минуты (из-за того, что передаваться всё равно будет ограниченными блоками). нормальный файл размером гигабайт будет передаваться несколькими часами больше, не говоря уже о передаче по eMule.
Что мы делаем: нам известно, что человеку требуется какой-то файл, он стоит за ним в очереди. Мы берём этот файл (если он у нас есть) и подменяем таким же по размеру, но полностью забитым нулями. Хэш оставляем прежний. За считанные минуты клиенту передадутся десятки мегабайт информации и наш рейтинг сразу же резко повысится. А человек потом сверит полученные данные с хэшем, и будет выкачивать файл заново, но у нас рейтинг уже есть. Стоит отметить, что если человек постоянно повторно выкачивать у вас "нулевой" кусок файла, то очень быстро обман вскроется. Поэтому желательно проследить тот момент, когда он будет закачивать уже концовку девятимегабайтного блока и быстро его отрубить, пока он не начал сверять части - в этом случае успех гарантирован. Вообще даже не обязательно иметь исходный файл - можно создать такой файл в ручную, дописав нужный хэш - Мул проверять ничего не станет, но о форматах файлов я расскажу уже в следующий раз, ограничившись в этой статье лишь кратким перечислением.
Как защититься от подобной "накрутки"? Никак. Только если разработчики обратят внимание на эту статью и усовершенствуют в будущих версиях алгоритмы проверки. Единственное, как можно бороться - блокировать тем или иным способом подобных "хакеров". Самое простое - с помощью файрволла. Так же, если покопаться в файлах Мула, можно забанить недоброжелателей или сбросить весь их рейтинг, что проще. Но об этом уже в следующий раз.
Однако я просто не могу не сказать, что приведённый способ лучше не использовать. Не потому что за это могут посадить или набить морду - просто это не хорошо. Всё-таки eMule - это сообщество, где люди бескорыстно делятся, и засорять его всякой гадостью не хочется. Комьюнити однако. Данный способ я привёл исключительно в целях теоретического интереса.
Приложение I. Файлы eMule
(данное приложение является переводом с небольшими поправками официальной документации: http://www.emule-project.net/home/perl/help.cgi?l=1&topic_id=106&rm=show_topic)
known.met - здесь сохранена вся информация о всех файлах, с которыми когда-либо доводилось работать Мулу (расшаренные, скаченные, те, которые качаются в данный момент). Содержит их названия, размеры, статистику, адреса и хэши.
clients.met - информация обо всех пользователях, которые когда-либо что-либо качали или отдавали пользователю.
servers.met - содержит все известные серверы..
emfriends.met - список друзей.
preferences.ini - содержит все настройки Мула (часть из них доступна только из этого файла).
fileinfo.ini - комментарии и оценки расшаренных файлов.
category.ini - хранит информацию о всех категориях.
ipfilter.dat - содержит информацию об ip-фильтре.
onlinesig.dat - содержит в себе "online signature" - статистику о даунлоаде/аплоаде.
preferences.dat - содержит хэш пользователя.
sharedir.dat - содержит пути до всех расшаренных директорий.
staticservers.dat - содержит информацию о постоянных (статических, не меняющих IP и постоянно работающих) серверах.
adresses.dat - если в нём указан адрес до некоторого файла server.mets, то каждый раз при загрузке eMule будет обновлять свой список оттуда.
ac_searchstrings.dat - содержит все поисковые запросы, когда-либо проводившиеся.
ac_servermeturls.dat - аналогичен adresses.dat, с той разницей, что содержит сразу несколько адресов, где брать списки серверов. Из списка ищет первый рабочий (хотя я в этом не уверен - на официальном сайте разъяснений нет, а мне не было нужды разбираться).
cryptkay.dat - содержит в себе ключ RSA для безопасной аутентификации.
emule.tmpl - содержит шаблон для веб-сервера eMule (тот что в настройках выставляется для удалённого администрирования).
xxx.part - незаконченная закачка (то, что качается в данный момент). xxx - число.
xxx.part.met - содержит информацию о закачках (Part Hashes). Такой файл сопровождает любой файл .part
xxx.part.met.bak - запасной .part.met-файл, который создаётся на случай повреждения основного.
emule.log - сохраняет лог-файл Мула. Работает только если включено расширенное управление.
emule_debug.log - сохраняет лог дебага. Работает только если включено расширенное управление.
Приложение II. Простейшие компьютерные термины, используемые в статье.
(Для новичков за компьютером и в Интернете. Я допускаю в описании некоторые незначительные неточности - для меня самым главным является донести понимание, а не научить разбираться в маршрутизации и иерархии DNS)
Installer (Инсталлер) - програма, которая устанавливает что-то на компьютер
Бинарник - сама программа, не требующая установки. Чаще всего не работает и предназначена либо для специалистов, либо для обновлений, поскольку её ещё нужно настраивать, чем обычно занимается инсталлер. Однако это всё больше относительные и жаргонные выражения - вполне возможно может встретиться и другая интерпритация.
Порт - каждый компьютер имеет множество портов. Если на компьютере загружено несколько интернет-приложений, то каждому из них соответствует один или несколько портов. Соединение с конкретной программой происходит по адресу и по номеру порта - это как идентификатор программы.
Ник (nick) - псевдоним
Инет - Интернет
Протокол - "язык", на котором общаются между собой два компьютера по сети. Их большое множество, чаще всего они оговорены какими-либо стандартами
Расшарить - сделать общедоступным
Лимит - предел, за который нельзя выходить
IP - уникальный адрес компьютера в Интернет (устанавливается для каждого компьютера при входе в Сеть). Имеет вид "a.b.c.d", где a, b, c, d - целые числа от 0 до 255. Бывают статическими, когда у компьютера адрес постоянный, и динамическими, когда при каждом входе в Сеть компьютеру присваевается новый IP.
Домен - адрес сервера. Например, "heller.ru", "emule-project.net". В действительности является синонимом IP-адреса.
Юзер - пользователь
Аутентификации - процесс, когда чужой компьютер какими-либо методами устанавливает подлинность того, что вы являетесь тем, за кого себя выдаёте.
Проводник - программа Windows для управления файлами и папками.
LAN - локальная сеть
CPU - процессор
Предпросмотр - просмотр куска ещё не скачанного до конца файла
Хэш - результат вычисления над данными некоторой функции, которая потом может служить как доказательство целостности данных. Если от них опять вычислить хэш-функцию и она будет отличаться, то значит что и сам файл изменён. Хэш по объёму значительно меньше данных, для которых он вычислялся (бывают исключения, но не в данном случае).
MD4, SHA-1 - известные хэш-функции
RSA - система шифрования, которая часто применяется в схемах аутентификации.
Браузер - программа для просмотра страниц Интернета (чаще всего Internet Explorer)
Цифровая подпись - средство для установления подлинности автора. Часто используется в системах аутентификации.
Даунлауд (Download) - скачивание
Аплоуд (Uploud) - закачивание. В русском написании для Download и Upload могут быть различные варианты - конкретного правописания не существует - все пишут кто во что горазд.
Трафик - объём передачи информации по Интернету
Провайдер (ISP) - фирма, которая предоставляет доступ в Интернет и через оборудование которой вся информация из Интернета попадает к вам на компьютер.
