информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаSpanning Tree Protocol: недокументированное применениеЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
proxy 24.11.02 18:09  Число просмотров: 1584
Автор: Konstantin <Konstantin Leontiev> Статус: Member
<"чистая" ссылка>
> [...]
> > Насчёт каскадных прокси - сами понимаете... Вещь не
> > простая.. Но мы постараемся. Я думаю после нового года
> > можно будет уже и о тестировании каскадного прокси
> > говорить.
>
> Насколько я понимаю, просто при запросе блоков (юнитов),
> прокси должен выглядеть как клиент, только с большими
> запросами и соответствующим ID. Ну и начать, собственно,
> можно с некаскадируемого варианта, хотя, для отслеживания
> работы нескольких сетей, это и менее удобно, но для запуска
> проекта приемлемо.

Сейчас есть возможность расшаривать КЕШ который пополняется и отправляется одним клиентом, а обсчитывают задания в нём много клиентов. Если разместить КЕШ на шареном файловом ресурсе, и немного настроить client.ini то двухуровнявая архитектура уже будет работать.
<dnet>
Проект MD@home можно считать открытым. 23.11.02 22:53  
Автор: Konstantin <Konstantin Leontiev> Статус: Member
Отредактировано 24.11.02 01:19  Количество правок: 4
<"чистая" ссылка>
Ну вот! Можно считать дипептиды.
Официально объявляю проект открытым.

Не все из важных замечаний мы учли в клиентской части.. Сейчас идёт разрабока следующей версии клиента. Но и эта уже удовлетворяет многим из предявленных её требованиям.

В следующей версии:
1) Сворачивание в трей.
2) Инсталляция как сервис в WinNT/2K/XP.

Дополнительные подробности см. на форуме http://distributed.org.ru/

ссылка: http://www.moldyn.ru/

http://www.moldyn.ru/
Точно? 25.11.02 17:28  
Автор: Deviator <n/a> Статус: Member
<"чистая" ссылка>
решил потестировать клиента, запускаю - получаю:

-----------
Trying to initialise and run calculation thread:

================= Distributed Caclulations =================

DNet_Thread: runing get/send thread.
Server WWW.MOLDYN.RU say that no WU's available now.

DNet_Thread: stoped get/send thread.
-----------

версия: 1.15.1a
3 разА запускал, PHP минуты 2 покряхтит и клиент встаёт с вышеприведённым сообщением.
типа, вопрос возник: "кто виноват и что делать?"
У меня так было, пока GUID не прописал 25.11.02 18:40  
Автор: Kost <Пробки Москвы> Статус: Elderman
<"чистая" ссылка>
> решил потестировать клиента, запускаю - получаю:
> -----------
> Trying to initialise and run calculation thread:
>
> ================= Distributed Caclulations
> =================
>
> DNet_Thread: runing get/send thread.
> Server WWW.MOLDYN.RU say that no WU's available now.
>
> DNet_Thread: stoped get/send thread.
> -----------
1) user_guid= не забыл прописать?
2) что в distributed.log?
обижаете :) 25.11.02 22:56  
Автор: Deviator <n/a> Статус: Member
<"чистая" ссылка>
На сколько я в курсе, идут какие-то серьезные изменения в серверной части. 25.11.02 18:07  
Автор: Night Knight [HZTeam.msk] <George Fedosejev> Статус: Member
<"чистая" ссылка>
На сколько я в курсе, идут какие-то серьезные изменения в серверной части. 25.11.02 20:47  
Автор: Konstantin <Konstantin Leontiev> Статус: Member
<"чистая" ссылка>
Они не сколько не должны сказываться на то что работает сейчас. Более того мы это наблюдаем. Т.е на всех машинах на которых мы это тестируем проблем нет.. Надо смотреть конкретно distributed.log и client.ini
На сколько я в курсе, идут какие-то серьезные изменения в серверной части. 25.11.02 23:00  
Автор: Deviator <n/a> Статус: Member
<"чистая" ссылка>
> Они не сколько не должны сказываться на то что работает
> сейчас. Более того мы это наблюдаем. Т.е на всех машинах на
> которых мы это тестируем проблем нет.. Надо смотреть
> конкретно distributed.log и client.ini

похоже, он через мой роутер не могет прорваться, вот сейчас из дома (директом по модему) взял блок и чего то начал шуршать, завтра попробую время найти - пошарить по логам прокси. кстати, невредно было бы иметь возможность конектиться через SOCKS4, он аутеитефикации не требует и портами на роутере в нём проще рулить
На сколько я в курсе, идут какие-то серьезные изменения в серверной части. 26.11.02 00:00  
Автор: Konstantin <Konstantin Leontiev> Статус: Member
<"чистая" ссылка>
> > Они не сколько не должны сказываться на то что
> работает
> > сейчас. Более того мы это наблюдаем. Т.е на всех
> машинах на
> > которых мы это тестируем проблем нет.. Надо смотреть
> > конкретно distributed.log и client.ini
>
> похоже, он через мой роутер не могет прорваться, вот сейчас
> из дома (директом по модему) взял блок и чего то начал
> шуршать, завтра попробую время найти - пошарить по логам
> прокси. кстати, невредно было бы иметь возможность
> конектиться через SOCKS4, он аутеитефикации не требует и
> портами на роутере в нём проще рулить

Как только изучу спецификацию SOCKS4 - сделаю. Если поможете или подскажите библиотеку сделаю быстрее.
проблемы 26.11.02 10:04  
Автор: Deviator <n/a> Статус: Member
<"чистая" ссылка>
> Как только изучу спецификацию SOCKS4 - сделаю. Если
> поможете или подскажите библиотеку сделаю быстрее.

это давайте отложим, поскольку есть куда более существенные проблемы, да и помошник я в этом почти никакой - моё дело правильно настроить уже готовое.

Логи отослал на мыло (кот. указано для этого), а впечатления помимо... - это, конечно, никакой не релиз-кандидат, это почти полноценная альфа...

Максимум, что удалось добиться в рабочей сети - скачать входные блоки. Даже при наличии полных входных буферов, клиент запускает PHP (!), мало того, это же происходит при указании работы только с локальными буферами (!), т.е. на настройки клиент просто не реагирует (?).

Если соответствует действительности сообщение: http://www.bugtraq.ru/cgi-bin/forum.cgi?type=sb&b=1&m=65128 о размере выходных буферов, то с софтом, вообще, можно не торопиться - трафик в размере >1Gb в мес. ни для меня, ни для большинства сетевиков просто нереален. Что бы быть реальным, он должен быть, хотя бы, в 50 раз меньше и то это много, но хоть как то представимо. Иначе проект попадёт исключительно в разряд курьёзов, а его имя, боюсь, станет нарицательным.

Возвращаясь к началу всей дискуссии по теме, всё женастоятельнорекомендую изучить опыт уже имеющихся проектов, как успешных, так и нет - что считать успехом, каждый решает сам. MoDyp пока, гораздо больше похож на F@H и аналоги, чем на DNet.
проблемы 26.11.02 18:26  
Автор: StR <Стас> Статус: Elderman
<"чистая" ссылка>
> каждый решает сам. MoDyp пока, гораздо больше похож на F@H
> и аналоги, чем на DNet.
Он и не может быть похож на днет... класс задач совершенно другой...
я имею ввиду похожесть подходов, а не внешние признаки 26.11.02 19:12  
Автор: Deviator <n/a> Статус: Member
<"чистая" ссылка>
Что _именно_ Вы имеете в виду под выражением "такие же подходы"? 26.11.02 20:23  
Автор: Konstantin <Konstantin Leontiev> Статус: Member
<"чистая" ссылка>
подходы + 27.11.02 00:03  
Автор: Deviator <n/a> Статус: Member
<"чистая" ссылка>
Под подходом, я подразумеваю, в первую очередь:

- способ организации проекта (т.е. что является исходной точкой), для проектов SETI, F@H, MoDyp это некая прикладная задача, которую хотелось бы решить до того, как её решение потеряет смысл ввиду старения вселенной. D-Net шёл с другой стороны, по принципу: "давайте организуем механизм, позволяющий раскидать решение сложных задач на незанятые процессоры, а заказчики найдутся" (естественно, я немного утрирую, но только немного);

- кто организует проект, для D-Net это люди решившие заниматься _распределёнными вычислениями_, "по барабану" какими, остальные проекты организовывались "заинтересованными лицами" (опять же с долей утрирования);

- "целевая аудитория", т.е. кого предпочитают привлекать организаторы в качестве доноров, D-Net "целится" в "скучающих сетевиков", остальные в "сознательных энтузиастов" (проявляется это, в первую очередь, в способе отображения процесса работы софта).

БОльшая часть остального вытекает из вышеперечисленного: это и "фантики и бантики" у всех клиентов, кроме D-Net'овского, и наличие единственного полноценного прокси, а так же клиента под платформы про существование которых я, к примеру, узнал из списка доступных клиентов... (но уже наоборот, только у них), и способ ведения логов и стата, и мотивация участников (полезность vs азарт)... Т.е. D-Net во главу угла ставит принцип: "входить тихо и быстро, не высовываться и не мешать тому, что работает, отваливать по первому требованию не оставляя следов", остальные этим похвастаться совсем не могут.

Собственно, дальше говорить нет смысла - это уже следствия. Естественно, что ошибки (организационного плана) бывают у всех и не D-Net'овские проекты не полностью аналогичны, я говорю только об исходных посылках (бизнес-моделях) этих проектов.

Теперь о '+' (кот. в заголовке).
Похоже мне удалось смоделировать ситуацию, в кот. клиент создаёт себе проблему с (возможно, только с распределённым) кэшем. Запускаем клиента при отсутствии юнитов в папке кэша и невозможности связи с сервером раздачи - он делает указанное кол. подпапок под юниты, лезет в и-нет и отваливается, при этом файл: "last-wu.dat" не создаётся. После этого, запускаем клиента с доступом в и-нет - он находит готовые папки, набивает их юнитами... и опять не создаёт файл: "last-wu.dat", после чего тыкается то в и-нет, то в папки юнитов, а делать ничего не хочет - файлА то нету... Видимо, нужен механизм проверки целостности кэша и доп. механизм контроля раздачи юнитов, например, на основе атрибутов папок или файлов.
подходы + 27.11.02 18:55  
Автор: StR <Стас> Статус: Elderman
Отредактировано 27.11.02 18:59  Количество правок: 1
<"чистая" ссылка>
> Под подходом, я подразумеваю, в первую очередь:
> - способ организации проекта (т.е. что является исходной
> говорю только об исходных посылках (бизнес-моделях) этих
> проектов.
В общем согласен, но бизнес-модель завязывается на техническую модель, которая зависит от класса задачи...
Тот же днет (бизнес-модель) ориентирован на задачи полного перебора с ответом типа да/нет, цель md - получить максимальное количество информации для каждого элемента задачи, поэтому сделать "свой днет" не получится... не уверен даже, что вообще можно нормально положить эту задачу на распределенные вычисления, как раз из-за желательности максимального объема ответа...
кстати и с соревновательностью будут сложности...
подходы + 27.11.02 19:46  
Автор: Konstantin <Konstantin Leontiev> Статус: Member
<"чистая" ссылка>
> > Под подходом, я подразумеваю, в первую очередь:
> > - способ организации проекта (т.е. что является
> исходной
> > говорю только об исходных посылках (бизнес-моделях)
> этих
> > проектов.
> В общем согласен, но бизнес-модель завязывается на
> техническую модель, которая зависит от класса задачи...
> Тот же днет (бизнес-модель) ориентирован на задачи полного
> перебора с ответом типа да/нет, цель md - получить
> максимальное количество информации для каждого элемента
> задачи, поэтому сделать "свой днет" не получится... не
> уверен даже, что вообще можно нормально положить эту задачу
> на распределенные вычисления, как раз из-за желательности
> максимального объема ответа...
> кстати и с соревновательностью будут сложности...

Ну почему же... Мы пожмём результаты и нужны же не все возможные результаты а лишь самые необходимые. :)
на оба постинга 27.11.02 22:03  
Автор: Deviator <n/a> Статус: Member
<"чистая" ссылка>
> > > Под подходом, я подразумеваю, в первую очередь:
> > > - способ организации проекта (т.е. что является
> > исходной
> > > говорю только об исходных посылках
> (бизнес-моделях)
> > этих
> > > проектов.
> > В общем согласен, но бизнес-модель завязывается на
> > техническую модель, которая зависит от класса
> задачи...

Вот в том то и дело, что сначала бизнес-модель, а исходя из неё (естественно, не только из неё, но не паралельно, не до, а после) составляется техзадание. Эксперименты по установке лошади и телеги в различные конфигурации уже проведены, результаты получены и нет никакой необходимости снова и снова прыгать с балкона, для того, что бы убедиться в дествии законов Ньютона.

> > Тот же днет (бизнес-модель) ориентирован на задачи
> полного
> > перебора с ответом типа да/нет, цель md - получить
> > максимальное количество информации для каждого
> элемента
> > задачи, поэтому сделать "свой днет" не получится... не
> > уверен даже, что вообще можно нормально положить эту
> задачу
> > на распределенные вычисления, как раз из-за
> желательности
> > максимального объема ответа...

Возможно, но что бы коментировать эту часть, надо хоть какое-то представление о предмете иметь, а я кроме названия ничего об этом не знаю. Единственное соображение - если количество результатов само по себе становится проблемой (а мне кажется, что это вполне может случиться), то налицо нерациональная постановка задачи. Впрочем, это совершенно умозрительное соображение, а соответственно, не имеющее содержательных оснований.

> > кстати и с соревновательностью будут сложности...

Вот это целиком зависит от толковости организаторов - если посмотреть ТиВи, так чем только пиплы не меряются...:)

> Ну почему же... Мы пожмём результаты и нужны же не все
> возможные результаты а лишь самые необходимые. :)

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

Спасибо за "+". Ошибка была немного в другом. Если папка где надо создать структуру кеш существовала (не её вышележащая папка, а она сама), то он не создавался... Это я только что пофиксил. Но всё равно большое спасибо.


По первой части если честно - нет просто времени клавиатуру топтать... У меня сейчас другой азарт. :)
проблемы 26.11.02 10:23  
Автор: Konstantin <Konstantin Leontiev> Статус: Member
<"чистая" ссылка>
> > Как только изучу спецификацию SOCKS4 - сделаю. Если
> > поможете или подскажите библиотеку сделаю быстрее.

А я то думалл ссылочку на библиотеку бесплатную какую дадите.

> это давайте отложим, поскольку есть куда более существенные
> проблемы, да и помошник я в этом почти никакой - моё дело
> правильно настроить уже готовое.
>
> Логи отослал на мыло (кот. указано для этого), а
> впечатления помимо... - это, конечно, никакой не
> релиз-кандидат, это почти полноценная альфа...

Ответ на мыло дал. Я думаю там всё просто.

> Максимум, что удалось добиться в рабочей сети - скачать
> входные блоки. Даже при наличии полных входных буферов,
> клиент запускает PHP (!), мало того, это же происходит при
> указании работы только с локальными буферами (!), т.е. на
> настройки клиент просто не реагирует (?).

Что касается запуска PHP на нём ещё пока кеш сделан.
И выборка элементов из него. А то что он в логах get и send пишет не пугайтес никуда он не коннектиться. Это просто процедуры которые как только видят, что коннект запрещён сразу завершаються

> Если соответствует действительности сообщение:
> http://www.bugtraq.ru/cgi-bin/forum.cgi?type=sb&b=1&m=65128
> о размере выходных буферов, то с софтом, вообще, можно не
> торопиться - трафик в размере >1Gb в мес. ни для меня,
> ни для большинства сетевиков просто нереален. Что бы быть
> реальным, он должен быть, хотя бы, в 50 раз меньше и то это
> много, но хоть как то представимо. Иначе проект попадёт
> исключительно в разряд курьёзов, а его имя, боюсь, станет
> нарицательным.

Ну во превых трафик исходящий, я не настаиваю. Сама задача такова, что в 50 раз мы не снизим объём результирующих данных даже если очень напряжёмся. Максимум 10 и то в лучшем случае. Результатом перебора диапазона чего-то на вшивость является одно число из него (в идеале 64 бита :) в вашем самом успешном проекте). А в нашей науке на самом деле данных нам нужно ещё больше чем сейчас отсылается... Просто мы понимая ценность трафика поумерили свой пыл до минимума. И если нам ещё удасться, максимум можно ожидать что результат на одно WU будет около 60-100Кб - третьего не дано. Если вам тяжело работать с такими объёмами, то я не могу на этом настативать - в любом случае спасибо за помошь!

> Возвращаясь к началу всей дискуссии по теме, всё же
>настоятельнорекомендую изучить опыт уже имеющихся
> проектов, как успешных, так и нет - что считать успехом,
> каждый решает сам. MoDyp пока, гораздо больше похож на F@H
> и аналоги, чем на DNet.

Я уже это понял :).
трафик 26.11.02 11:55  
Автор: Deviator <n/a> Статус: Member
<"чистая" ссылка>
[...]
> Сама задача
> такова, что в 50 раз мы не снизим объём результирующих
> данных даже если очень напряжёмся. Максимум 10 и то в
> лучшем случае.
[...]
> И если нам ещё удасться, максимум можно ожидать
> что результат на одно WU будет около 60-100Кб - третьего не
> дано.

Может и не дано, а мож поискать надо...

Если просто жать результаты универсальным архиватором, то, действительно, о радикальном изменении размера, речь не пойдёт, но вот если подойти с другой стороны..., как обычно, сзади... :)

Во-первых, проанализировать формат результатов на предмет внутренней избыточности, например, можно ли представить результаты в относительном формате (т.е. "от предыдущего"), логарифмическом или ещё как то компактнее, чем уже есть.

Во-вторых, проанализировать "глубину" обработки - нельзя ли за счёт большей обработки исходных данных прийти к более компактному результату, или отбросить заведомо неинтересные результаты - естественно, что считать интересным, решать постановщикам задачи.

В-третьих, после всего этого связаться со специалистами по разработке архиваторов (с тем же Рошалем) и попытаться "вытрясти" из них специализированый архиватор именно для ваших данных - разница в упаковке может быть просто колосальной.

Естественно, такой проект плод "миллиона" компромисов и каждый вовлечённый в него, будет "тянуть одеяло на себя", я то-же :).
трафик 26.11.02 11:34  
Автор: Kost <Пробки Москвы> Статус: Elderman
<"чистая" ссылка>
Давайте немного посчитаем.
1) Константин, а сколько входящего трафика при закачивании одной WU с сервера клиенту?
2) К этой величине добавится порядка 7-10% от исходящего трафика (в TCP не бывает потока данных строго в одном направлении). Это сейчас немного, но может иметь значение в случаях домашних сетей, где люди платят из своего кармана центов по 15 за мегабайт.

> минимума. И если нам ещё удасться, максимум можно ожидать
> что результат на одно WU будет около 60-100Кб

Пока идет первый этап проекта, это не вопрос, подумаешь, 400 WU на всех.
Вот когда начнется следующий этап и потребуются большие вычислительные мощности, размер WU может стать препятствием.
1  |  2  |  3 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach