POV-Ray : Newsgroups : povray.general : Peer to Peer Povray Server Time
8 Aug 2024 10:22:13 EDT (-0400)
  Peer to Peer Povray (Message 21 to 23 of 23)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Laszlo Vecsey
Subject: Re: Peer to Peer Povray
Date: 20 Mar 2001 09:43:07
Message: <3ab76c7b@news.povray.org>
"Gilles Tran" <tra### [at] inapginrafr> wrote in message
> While I've no doubt about Povray being a good test case for this, the main
> problem is about the usefulness of it for end users - a least for those
who
> create stills. Scenes that render slowly (let's say below 10 pps - roughly
> an overnight render at 800*600) and that could benefit from it are often
> (but not always) ones that also use large amounts of memory and disc
space,
> which would make their distribution uneasy.

For scenes that are reasonable in terms of memory use, images, etc,
non-radiosity -- eliminating all the major issues - then the next thing to
have to develop a user interest would be to let the end users view the
renderings that their machines are computing.

This way when you return to your computer you can see something partially
rendered and link back to a centrally controlled website that has stats on
all the parts of the scene, the author, originating IP of the job, and so
on.

In this way a community could be built up primarily using this network for
final-output of high resolution images or some such.. or test renders at
high res that will be completed relatively quickly

In fact don't even link back to a website, but just have a little status
window available that shows the information, and perhaps a link back to that
users home page and email address if they choose to provide it :)

The user can optionally provide access to his 'rendering' directory so that
others can view the completed images, or past renderings. In this way you're
relatively detached from the web and there is no central repository as such


Post a reply to this message

From: Gilles Fedak
Subject: Re: Peer to Peer Povray
Date: 25 Mar 2001 12:18:42
Message: <3ABE2885.1CC5F251@lri.fr>
"Peter J. Holzer" wrote:

> I have downloaded the program, but I couldn't find much information on
> how it works, and - most importantly - no source code on the site.

You're right. I will put an access to the source code throught CVS this
week. 
You'll see that it's quit simple to get in the code. 
Keep in mind that it is still under development.

Gilles    Equipe Architectures Paralleles   Tel  33  01-69-15-42-25 
FEDAK     LRI bat 490                       Fax  33  01-69-15-65-86
------    Universite Paris-Sud                  email: fed### [at] lrifr
XtremWeb  F-91405 ORSAY Cedex              http://www.lri.fr/~fedak


Post a reply to this message

From: Gilles Fedak
Subject: Re: Peer to Peer Povray
Date: 25 Mar 2001 12:59:15
Message: <3ABE3206.3E951529@lri.fr>
"Peter J. Holzer" wrote 
> RLIMIT_CPU
>     (limits the total CPU usage for one job)
> 
> RLIMIT_DATA, RLIMIT_STACK, RLIMIT_CORE
>     (limits the memory usage of a single process not all unixes have all
>     of these)
> 
> RLIMIT_NPROC
>     (limits the number of processes per user)
> 
> RLIMIT_NOFILE
>     (limits the number of open files per process)
> 
> Together with quotas, a chrooted environment and a positive nice factor,
> the povray process(es) would be restricted from disturbing their host
> computer.

An other approach we are concidering is to confine the execution in a
sandbox. 
Last week we have played with user-mode-linux.
(http://www.user-mode-linux.sourceforge.net)

Idea is to boot a virtual os only to run the application (povray). So
even if Povray is compromised, the user
is still in the sandbox and don't have access to the hosting machine.
Some preliminary test show that this solution 
is quite easy to use. More, it has cool features such as defining the
amount of memory (physical and swap)
 the process may use, the amount of disk and so on... So it is a very
appealing solution.

But we are still checking security and performance issues. 
We are also comparing it to other solution also PTRACE oriented like
Janus or subterfugue (http://subterfugue.sourceforge.net)


> You can leave this to the slave servers: They can check whether there is
> some output produces within a given time. If there isn't, they'll kill
> the process and report failure.
> 

Yes, it's the only way, unless that the server could be constantly
overloaded.



-- 
Gilles    Equipe Architectures Paralleles   Tel  33  01-69-15-42-25 
FEDAK     LRI bat 490                       Fax  33  01-69-15-65-86
------    Universite Paris-Sud                  email: fed### [at] lrifr
XtremWeb  F-91405 ORSAY Cedex              http://www.lri.fr/~fedak


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.