Под подходом, я подразумеваю, в первую очередь:
- способ организации проекта (т.е. что является исходной точкой), для проектов SETI, F@H, MoDyp это некая прикладная задача, которую хотелось бы решить до того, как её решение потеряет смысл ввиду старения вселенной. D-Net шёл с другой стороны, по принципу: "давайте организуем механизм, позволяющий раскидать решение сложных задач на незанятые процессоры, а заказчики найдутся" (естественно, я немного утрирую, но только немного);
- кто организует проект, для D-Net это люди решившие заниматься _распределёнными вычислениями_, "по барабану" какими, остальные проекты организовывались "заинтересованными лицами" (опять же с долей утрирования);
- "целевая аудитория", т.е. кого предпочитают привлекать организаторы в качестве доноров, D-Net "целится" в "скучающих сетевиков", остальные в "сознательных энтузиастов" (проявляется это, в первую очередь, в способе отображения процесса работы софта).
БОльшая часть остального вытекает из вышеперечисленного: это и "фантики и бантики" у всех клиентов, кроме D-Net'овского, и наличие единственного полноценного прокси, а так же клиента под платформы про существование которых я, к примеру, узнал из списка доступных клиентов... (но уже наоборот, только у них), и способ ведения логов и стата, и мотивация участников (полезность vs азарт)... Т.е. D-Net во главу угла ставит принцип: "входить тихо и быстро, не высовываться и не мешать тому, что работает, отваливать по первому требованию не оставляя следов", остальные этим похвастаться совсем не могут.
Собственно, дальше говорить нет смысла - это уже следствия. Естественно, что ошибки (организационного плана) бывают у всех и не D-Net'овские проекты не полностью аналогичны, я говорю только об исходных посылках (бизнес-моделях) этих проектов.
Теперь о '+' (кот. в заголовке).
Похоже мне удалось смоделировать ситуацию, в кот. клиент создаёт себе проблему с (возможно, только с распределённым) кэшем. Запускаем клиента при отсутствии юнитов в папке кэша и невозможности связи с сервером раздачи - он делает указанное кол. подпапок под юниты, лезет в и-нет и отваливается, при этом файл: "last-wu.dat" не создаётся. После этого, запускаем клиента с доступом в и-нет - он находит готовые папки, набивает их юнитами... и опять не создаёт файл: "last-wu.dat", после чего тыкается то в и-нет, то в папки юнитов, а делать ничего не хочет - файлА то нету... Видимо, нужен механизм проверки целостности кэша и доп. механизм контроля раздачи юнитов, например, на основе атрибутов папок или файлов.
|