[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Part 2: System Structure

From: Michal Suchanek
Subject: Re: Part 2: System Structure
Date: Mon, 15 May 2006 13:11:36 +0200

On 5/15/06, Marcus Brinkmann <address@hidden> wrote:
At Sat, 13 May 2006 12:24:31 +0200,
Pierre THIERRY <address@hidden> wrote:
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Scribit Bas Wijnen dies 13/05/2006 hora 08:59:
> > I do see one problem with this approach though.  If the game is a
> > service provided by some server, then the user doesn't pay for the
> > resources which are used by the game.
> Indeed. Without some ability to give resource usage along with request
> of using it, this won't work with games.

This is just because you are trying to do something that is very
complicated.  On the one hand, you want to run the competition on the
users resources, on the other hand, you want the competition to be
able to reliably update the high score file.  In these requirements
you are already presupposing DRM, plus opaque resource donation, plus
a non-confined "competition constructor" server, plus a careful
competition program design that runs some parts of the competition on
durable resources and some on non-durable resources.  All of this is
technically possible, but the complexity is inherent in the goal.

In Unix it just looks simpler because the resource accounting is sloppier.

The game problem is very similar to the problem with students that
should be able to examine the results of a program but not its code,
and that the teacher providing the code does not want (or cannot) run
enough instances of the program.

In this case the students only donate cpu time, and it is their data
that is processed I guess. The code is shared so there is no problem.
If the program needed temporary storage that should not be disclosed
it might be a problem, though.

In the case of the game it should not be a problem if the temporary
storage is disclosed. After all, the game is probably known, and a
copy that the user runs himself can be examined in any way he wishes.
However, the storage given to the game should not be writable by the
user as long as the game uses it (ie until it is revoked).
This is a restriction but I do not think it is DRM because the most
important purpose of DRM is not to disclose data.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]