EiskaltDC++ — Часто задаваемые вопросы
Создано: 2010-09-18Обновлено: 2013-07-12
Небольшой FAQ:
Q: Почему в EiskaltDC++ нет той или иной фичи, которая есть в FlylinkDC++ и StrongDC++ sqlite?
A: EiskaltDC++ никогда не перейдет на использование ядра StrongDC++ sqlite (не путать с оригинальным StrongDC++, см. схему ниже), которое так же используется во FlylinkDC++ (оба клиента развиваются одной командой разработчиков). Данное ядро сильно модифицировано и местами несовместимо с ядром оригинального DC++ и/или его производных (например, StrongDC++ и ApexDC++). Значительное количество собственных исправлений в коде ядра, сильно затрудняет его синхронизацию с актуальными версиями DC++. Базовое отличие ядра FlylinkDC++ во встроенной базе данных SQLite, все остальное лишь следствия. Например, хэш суммы файлов из шары FlylinkDC++ хранятся в файле базы данных, из-за чего вы не сможете перенести шару в DC++ или EiskaltDC++ простым копированием файлов из каталога настроек. Хэшировать все файлы придется заново (хотя, конечно, вы можете написать какой-нибудь конвертер, если есть время и желание). Между другими клиентами, основанными на ядре DC++, эти данные переносимы (см. бинарный файл HashData.dat).
Q: Почему в EiskaltDC++ нет разделения на демона и графический интерфейс?
A: Это нерациональная трата ресурсов. Вместо прямой передачи:
сообщение от ядра → обработка фронт-эндом
придется использовать:
сообщение от ядра → обработка демоном (кодирование сообщения) → декодирование сообщения фронт-эндом → обработка фронт-эндом
Т.е. есть несколько лишних ресурсоемких операций. Кроме того, для передачи информации в бинарном виде от демона к фронт-энду придется делать свой велосипед вне зависимости от способа передачи (сокеты, tcp или др.). Передавать сообщения в текстовом виде нельзя, т.к. там слишком большой поток информации в единицу времени.
Q: Но ведь в transmission это работает!
A: Transmission — это очень хороший торрент-клиент, с грамотной архитектурой. Но он работает по совсем другому протоколу.
В проколах NMDC и ADC передается значительно больше информации в единицу времени чем в торрентах. Например: сообщения о подключениях и отключениях пользователей, сообщения в чат, поисковые запросы и т.п.. Что заметно нагружает систему (загрузка процессора) на слабых машинах, когда пользователь подключен к нескольким крупным хабам, даже при существующей реализации DC-клиентов.
Большинство этих сообщений ядра значимы и их нельзя просто игнорировать. Например: сообщения о подключениях пользователей нужны для формирования актуального списка подключенных к хабу пользователей, т.к. никак иначе эту информацию получить нельзя.
Если же все-таки реализовать полноценное разделение на демона и фронт-энды, что мы получим в итоге?
Демон будет занимать заметное место в оперативе (необходимо хранить информацию перед передачей фронт-энду) и сильно загружать процессор при кодировании информации перед передачей фронт-энду. Т.е. на слабом роутере его использовать будет затруднительно...
Фронт-энд, который сможет подключаться к демону, вне зависимости от используемой ОС и архитектуры системы. Как сильно он будет нагружать процессор и какой потребуется передавать поток (трафик) от демона к нему зависит только от эфективности реализации сжатия информации (тот самый велосипед). Лучше сжатие → меньше трафик, но больше загрузка процессора, и наоборот...
Оно вам надо?..
Q: Вы добавили в ядро поддержку DHT. Зачем?!
A: Пользотелям локальных сетей DHT конечно не нужен. Более того — он им вреден, т.к. клиент будет загружать файлы из интернета по соответствующему тарифу... Но для пользователей без локальных сетей и/или с безлимитными тарифами на интернет этот функционал будет крайне полезен. Не волнуйтесь, данная опция по умолчанию будет отключена.
Реализация DHT в StrongDC++, которую мы используем, лишь в незначительных деталях отличается от реализации DHT в торрентах (en). Все базовые идеи и основные алгоритмы остались неизменны.
DHT для DC-сетей не зависит от хабов, так же как и DHT в торрентах не зависит от трекера. В настоящий момент в реализации DHT от StrongDC++ есть только обмен данными, но в будущем возможно будут реализованы так же приваты между нодами.
В качестве примера полезности DHT: после добавления некоторого количества файлов в список загрузок, клиент можно отключить от хабов и все файлы будут успешно загружены. Без использования DHT, при отсутствии подключения к хабам, клиент не сможет найти новых источников файлов и через некоторое время загрузки будут прекращены.
Разумеется, у DHT есть не только плюсы, но и минусы, о которых можно прочитать в соответствующей статье (en) на Википедии.
Q: Почему айскальт забанен на моем любимом хабе?
A: Причин может быть много... Например, при настройке хаба был использован старый конфиг скрипта, который блокирует все неизвестные ему клиеты. Или другой вариант: часто администраторы блокируют айскальт потому, что им не нравятся какие-либо функции клиента, которые так любят пользователи. Это такие фичи как: ограничение скорости загрузки и отдачи, ограничение минимального размера шары для раздач, IP-фильтр, антиспам (с возможностью игнорирования операторов хаба).
Q: Что же мне делать?
A: Для начала, можно установить в настройках данного избранного хаба идентификационный тег от другого DC-клиента, который точно не забанен на данном хабе. Но лучше всего, конечно, если вы можете обсудить данную проблему с администратором хаба. Будьте вежливы и постарайтесь изложить свою позицию последовательно и аргументировано. Надеюсь, что ваше общение будет продуктивным...
Q: Почему у программы не работает та или иная фича в Ubuntu?
A: Мы не поддерживаем Ubuntu Unity и GNOME Shell, потому что они продвигают свои нестандартные и несовместимые с другими DE решения, а их разработчики не уважают своих пользователей и труд других разработчиков.
Q: Как я могу сделать пожертвование?
A: Никак. Мы не принимаем пожертвования.
Лицензия: Public Domain (ru, en)
Заметка: Все представленные здесь материалы можно использовать частично или полностью без указания ссылок на автора (меня) и оригинальную страницу.