информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetГде водятся OGRыВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
ToDo 23.11.02 21:26  Число просмотров: 1479
Автор: Jammer (YRV) Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > 1)
> > USER MESSAGE: !!!!! NOW YOU CAN STOP MODYP !!!!!
> because no new WU's available.
> > и прекратит свою работу.

а может быть имеет смысл как раз ждать, пока экземпляр клиента на другой машине (имеющей сетевые полномочия) накормит "помощников"?

> > 2) Если для некоторых клиентов будет доступен только
> > сетевой кеш, то им незачем постоянно ломиться в инет.
> > Возможно нужно сделать еще одну опцию, что-то вроде
> > cache_type="local|inet", в зависимости от значения которой
> > клиентская часть будет или не будет пытаться
> устанавливать соединение через интернет.

у днета это настраивалось простым триггером в конфиге на разрешение/запрещение networking. имеет смысл перенять этот опыт, имхо.

> > 3) Если после обработки каждого WU "центральный", а тем
> > более каждый в сети, клиент будет пытаться установить
> > соединение с сервером, то это будет совершенно лишний
> > сетевой трафик. Здесть есть сисадмины с зоопарком в
> > несколько десятков, а то и сотен, машин. Для них такой
> > трафик будет представлять реальную угрозу работоспособности
> > сети. А суммарная нагрузка на ваш сервер/канал будет во
> > много раз сильнее. С течением времени пробиться за новыми
> > WU будет просто не реально. Как минимум, стоит сделать
> > некое ограничение на количество готовых WU, по
> достижении которого "центральный" клиент будет пытаться
> установить связь с сервером. IMHO.

это было хорошо реализовано в одной из старых версий dnetc - обмениваться с сервером (или по локальной сети), если: во входном буфере осталось<XИЛИв выходном накопилось>Y.

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

опять же, любой супернадежный выделенный канал иногда падает (и от этого не застрахована не только любая, даже весьма мощная сеть, участвующая в вашем проекте, но и сеть, в которой работает ваш сервер). более того, упасть и сервер может. хорошо бы, чтобы с момента падения до момента подъема у прожорливых сетей был необходимый запас. поэтому нельзя обмениваться и при полном опустении входного буфера. нужна золотая середина.
<dnet> Поиск 








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


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