Соединение. Здесь уже интересней. Позволяет выставить скорость, пределы на отдачу/загрузку, поменять порты (что в общем случае не нужно), указать сети, с которыми работать (должны быть отмечены обе галки), изменить максимальное число соединений и т. д. Там имеется кнопка "Помощник", нажимая на которую вы увидите окно, аналогичное тому, что было при первом запуске - там можно указать лишь наиболее важные параметры, такие как соединение и операционную систему, остальное eMule настроит сам, исходя из этих данных.
Прокси. Нужно, если вы хотите/используете прокси. Вещь в общем случае не нужная, так что этот пункт мы опустим. Сервер. Ряд не особо важных и достаточно очевидных настроек. Не сильно критично, поставите ли вы обновление списка серверов при включении или обновление списка серверов при соединении с сервером - главное, что бы они обновлялись хотя бы каким-нибудь образом. Остальное не столь важно (на связь оно так же не влияет, поскольку обновление в любом случае идёт только при установке соединения, что случается не так часто, да и сами списки достаточно маленькие по объёму). Единственное, что может вызвать непонимание - это безопасное соединение. Если вдруг при соединении с сервером вы получаете LowID, то если у вас указано безопасное соединение, вы будете пытаться подключаться к другим серверам. Если же соединение небезопасно, то вы так и продолжите работать с LowID (хотя проверки всё равно идут регулярно). Вообще LowID просто так присваивается достаточно редко - данная опция опять же не критична. Папки. Уже рассматривал. Установка расшаренных директорий, временной папки и папки для скачивания. Кстати, временная папка и папка для скачивания расшарены всегда по определению. Файлы. Опять же вполне очевидные настойки, не влияющие напрямую на скорость и качество скачивания.Уведомления. Настройка звуковых сигналов и всплывающих сообщений. Я обычно настраиваю для начала нового чата и нового сообщения.
Статистика. Если Мул отжирает много ресурсов, здесь можно замедлить сбор статистики, чем уменьшить загрузку процессора. Даже на средних компьютерах это не критично. IRC. Настройка IRC-сервера, ника, прочих настроек IRC. Безопасность. Здесь можно запретить соединения для пользователей с низким ID. Так же можно запретить соединения по конкретным IP-адресам, если вспомнить, каким образом генерируются эти самые ID. Так же имеется фильтр сообщений, который не будет пропускать сообщения, содержащие в себе перечисленные строки (несколько строк разделяются с помощью "|"). Аналогичный фильтр можно выставить и для комментариев к файлам. Опция "запуск eMule без привилегий Админа" доступна только в системах семейства NT (куда относится так же Windows 2000 и XP), хотя с ней имеется ряд проблем - в таком режиме Мул частенько начинает глючить, по большей части интерфейсом. Про безопасную идентификацию расскажу позже. Планировщик. Ещё одна настолько же полезная вещь, как и категории. Позволяет задавать изменение настроек eMul'а по расписанию. Понадобиться может только в том случае, если у вас Инет работает по расписанию, когда в зависимости от времени суток надо менять скорость, порты, адреса, сервера и прочее. Достаточно редкая ситуация. Создавать задачи достаточно просто. Единственное, что может вызвать затруднение - это задание действия для конкретного времени. Делается это с помощью правого клика по окну "действия". Web сервер. Вот это классная штука. Позволяет установить на ваш компьютер web-сервер для удалённого управления Мулом. Включается простым нажатием на флажок "включён". После вводите пароль и можете пользоваться. Веб-сервер будет иметь адрес http://ваш_ip:порт/. Если IP-адрес у вас динамический, то можно воспользоваться одной из следующих служб: http://directory.google.com/Top/Computers/Software/Internet/Servers/Address_Management/Dynamic_DNS_Services/ Они позволяют привязать к компьютеру адрес вида "домен.сервис.com", IP которого будет соответствовать вашему компьютеру и который будет меняться, если меняется ваш IP. Тогда по конкретному адресу вы всегда сможете управлять своим Мулом. Управление достаточно простое - веб-интерфейс практически полностью дублирует сам Мул. Установленный флажок gzip-сжатия указывает на то, что сервер должен поддерживать сжатие трафика. Нужная вещь, которая поддерживается любым браузером и позволяет повысить скорость передачи, уменьшив объёмы передаваемых данных. Шаблон emule.tmpl содержит непосредственно шаблон для веб-интерфейса. Другие шаблоны можно найти в сети или самому сделать, но это уже вещь исключительно оформительская. Опция "гость" открывает гостевой доступ до вэб-интерфейса, для него можно создать отдельно пароль. Пользователь, зашедший под гостем, может видеть всю информацию о Муле, но менять ничего не в силах. Следующий пункт MobileMule подключает утилиту, с помощью которой управлять Мулом можно с через мобильный телефон, поддерживающиуй Яву. Другие настройки. Здесь целая куча опций, не вошедших в остальные пункты, большая часть которых достаточно очевидна и не вызывает вопросов. Остановлюсь только на некоторых. Макс. число соединений за 5 sec: по умолчанию стоит 20. Увеличивать рекомендуется только в том случае, если имеется хороший канал Интернет, такой как LAN. Макс. полуоткрытых соединений: наибольшее количество соединений, которые открыты, но не используются в данный момент. Официальная рекомендация разработчиков eMule не делать это значение больше 9 для Windows XP SP2. Для остальных систем рекомендуется устанавливать это значение в 50. Вообще максимальное число полуоткрытых соединений влияет на скорость обмена источниками - чем меньше значение, тем медленнее будет идти обмен. В то же время после завершения обмена источниками, за счёт такого жёсткого запрета, скачивание будет идти быстрее, т. к. на эти соединения не будет потерь. Использовать кредитную систему: должна быть включена. Когда кредитная система работает, в вашей очереди пользователи продвигаются тем быстрее, чем больше они отдали вам. Это логично - давать больше выкачивать тем, кто вам полезен. С учётом того, что у тех, кто отдаёт вам, с большой степенью вероятности работает такая же система (а она работает по умолчанию во всех eMule-клиентах и в ряде других), это окажет хорошее влияние на ваши собственные закачки. Фильтр сервера и клиентов LAN IP: запрещает соединение с вами пользователей, IP которых не является IP Интернета. Если вы сами находитесь внутри локальной сети, то отключить её просто необходимо, иначе не сможете обмениваться с другими пользователями вашей сети (а даже если сеть небольшая, это достаточно полезно). В общем же случае данная опция защищает вас от появления некорректных источников. Пользователи, которые сами сидят в локалке, да ещё на кривых клиентах, могут по ошибке отправлять вам источники с указанием локального IP, который для вас значить ничего не будет. Не особо критичная настройка, но лучше оставить по умолчанию. Показать дополнительный контроль: при установленном флажке появляется ряд дополнительных возможностей Мула. К включению обязательна, но рассказывать про расширенные функции я буду опять же несколько позже.Отключить проверку ЗДФ для разгрузки CPU: эту опцию никогда не стоит включать. Особенно, если работаете в режиме дополнительного контроля. ЗДФ - это "запрошен другой файл". Если проверку отключить, то вы и знать не будете, что у вас такое происходит. В режиме дополнительного контроля всеми этими ЗДФ можно достаточно эффективно управлять, а CPU загружается не так уж и сильно. В английском варианте ЗДФ выглядит как "A4AF" (Asked For Another File, "for" часто на письме пишется просто как "4", поскольку и то и другое имеет одинаковое произношение).
Отключить скачивание с PeerCache: PeerCache это система, которая позволяет ускорить закачку и уменьшить трафик. Если у вашего провайдера несколько пользователей качают один файл (одновременно или в разное время - не важно), то этот файл у провайдера кэшируется и дальнейшее скачивание ведётся уже не из Интернета, а из кэша провайдера. Это и быстрее и дешевле, однако, должно поддерживаться на уровне самого провайдера. Какая ситуация с PeerCache происходит в России, автору не известно. В любом случае работающй PeerCache в Муле хуже не сделает - отключать его смысла нет. Безопасная запись .met/.dat: это файлы закачек. Ставить рекомендую максимально защищённый способ записи, а не только при выключении компьютера. Несмотря на то что существует целый ряд утилит для восстановления закачек после сбоев (например, отключения электричества), от их применения как-то легче не становится. Установка же максимальной защиты гарантирует вам, что после скачивания полугиговова куска он у вас не пропадёт после непредвиденной перезагрузки. Подробности. Описание интерфейса и настроек Мула закончено и теперь пора перейти к теории функционирования самой сети. Может показаться, что это уже ненужное углубление в детали, однако, понимание механизмов 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 - содержит пути до всех расшаренных директорий. staticse
Comments
программа
все когда то не
Отправить новый комментарий