WO2002031654A1

WO2002031654A1 - Distributed use of heterogeneous networked computers with billing

Info

Publication number: WO2002031654A1
Application number: PCT/DE2000/003553
Authority: WO
Inventors: Rainer Glaschick; Gerhard Schulz; Wolfgang Thronicke
Original assignee: Siemens Aktiengesellschaft
Priority date: 2000-10-10
Filing date: 2000-10-10
Publication date: 2002-04-18

Abstract

The invention relates to a method for using free computer capacity. According to this method, a conveyor conveys orders and has these orders processed several times for security.

Description

Distributed use of heterogeneous networked computers with billing

The invention relates to the use of networked heterogeneous computers, wherein the service called up by the computers is remunerated. It relates in particular to techniques in which otherwise unused computing power is used.

Very soon after the invention of the computer, operating systems were developed that initially, such as the operating system "IBSYS" for the computers of the "7040" and "7090" series from IBM, which had the task of using the computer as well as possible. Due to the progress of microprocessor technology in connection with the development of workstations with graphical user interfaces, the situation has arisen that the latter are mostly idle, because the computing power is only required as peak performance. Therefore, considerations and solutions have become known that should use this unused computing power wisely. A good overview of this can be found in the article by Brian Hayes, "Collective Wisdom", American Scientist, Vol. 86. No.2 (1998), p. 118-122. It describes in particular the already active applications such as "distributed.net" and "SETI @ home".

These applications have a number of things in common:

• These are defined applications, so that the "sponsor" has little or no concern that the application poses a security risk, • The supply of subtasks is much larger than the number of participants; that is, the total tasks can easily be divided into a very large number of subtasks,

• Lost orders are unproblematic for the result,

• The computing power is donated by the participants,

• The orders are managed and distributed from a central office; i.e. the head office is also the client,

• The time horizon of completion for the overall project is in the range of months to years rather than days,

• The required equipment is essentially computing time; on the other hand, little storage space is required,

• The processing time for a subtask can easily be a week, so that relatively rare access to the control center is necessary via the network.

In the last section of the above-mentioned article by Hayes, however, it is already mentioned that commercial use of the unused computing power is also conceivable, in which free computing power is offered and both are brought together via a central office. However, there are still a number of problems to be solved that have so far prevented actual use, including problems of security and confidentiality: • How is information prevented from being stolen from the computer?

• How is the order data prevented from being misused?

These problems are not relevant for the already known applications such as "distributed.net" and "SETI @ home".

Problems have not yet been named by Hayes, which result from the billing of computing power insofar as incorrect results are not simply given or the computing time required for this is overcharged. For this, it was necessary to make the computing power of the central processing units financially comparable.

According to Hayes, a solution is possible in principle, but no generally practicable solution is known yet,

It follows from the following description that this task is less difficult than was assumed, for example, by Hayes.

To simplify the description, the different roles are designated as follows:

Provider: ('tenderer') Provides orders ('Jobs') for processing and receives the results

Worker: ('Jobber') Fetches orders when computing power is free and delivers results.

A first measure is to introduce an agent ('conveyor'). This accepts the orders from the providers and lines them up in an order Queue on. At the same time, the workers ask the agent for orders. The essential function of the intermediary is to anonymize providers and workers against each other and to bill the services. Hayes has already proposed a 'clearinghouse'; however, it appears from the context that its primary task is to set prices according to supply and demand. However, Hayes lacks the knowledge that in the case of tasks that can be broken down into a large number of relatively independent orders, knowledge of a single or a small, randomly selected number of orders only allows the worker to use the entire task with great computing power close and get a significant amount of information. This principle is of great importance in cryptography: If a key is chosen as a random number, it is theoretically possible to decrypt the message with a second randomly chosen key. However, the low probability of success means that no attempt is made in the first place. If the provider is also unknown to the worker, his chances of illegally extracting information from the orders decrease. This is all the more so if the agent, who is known to the supplier and worker, takes into account when selecting the worker that no worker receives more than a predetermined percentage of the orders of a single class, which is specified by the provider. Since the class is not given to the worker, an (illegal) association of workers has practically no chance of stealing usable data from the orders. At the same time, the intermediary can solve the billing problem. In the simplest form, each job is sent to two different workers. First, the results have to be identical, and second, both workers are to be paid equally. It turns out that this deliberate "waste" of computing power ensures that manipulations are not worthwhile for the worker. After all, in this way the unused computing power of the Internet becomes commercially available and a large number of participants are tapped who have so far been of no interest due to the lack of incentive.

Simply because the agent and not the provider is the contractor of the worker, the latter also has practical security against the programs spying on his data. Aside from possible liability for damage, an agent who makes a mistake in this regard will usually immediately lose his workers to another agent, since switching to another agent is practically effortless for the worker.

The agent does not even have to save the data of the orders in his queue. In this case, the provider only transmits a URL with which an order can be called up from its server. This can also be a URL for dynamic data delivery, as can be reached with a CGI script. This information is put in the queue. A worker who wants to process such an order in turn receives a URL, but this is different from that of the provider. With this URL, the worker turns to the agent in the The way a 'proxy server' works. The latter then fetches the data from the provider and passes it on to the worker.

It is essential for the security of the solution that the orders are carried out by filters. Filters are programs that read exactly one input file sequentially and write exactly one output file sequentially. One of the simplest and most effective filters is a P-code interpreter. P-code stands for a virtual machine language designed for the PASCAL programming language, which was used by the first PASCAL compilers. A P-code interpreter for the original definition of PASCAL is designed for a filter function, so it cannot carry out any further system accesses. The input file then contains the P code of the program to be executed, certainly in a packed form, and then the input data. The interpreted program reads input line by input line and generates the corresponding output. If necessary, the program will temporarily store entries in arrays if a reset to the beginning is not intended. In any case, such a P-code interpreter is quite small in the source code and can therefore also be made available in the source code without any problems, so that it can be checked against security gaps during installation, if not the component that realizes the worker, is adopted by the intermediary as a binary file. In a variant, the worker first retrieves the entire input file and stores it temporarily on his own disk, then executes the job, also temporarily stores the output and then sends the output back "en bloc". This is special advantageous if the network connection is only temporary. Alternatively, one input and one output connection to the provider, usually via the intermediary, can be set up when the order is processed. Input lines are then buffered as long as there is space for them, and further requests are made via the connection after they have been used up. Accordingly, the output is buffered, but is regularly delivered via the output connection. This behavior is particularly useful when a large amount of data has to be processed. Analogous to the use of PASCAL, the use of JAVA, for which a virtual command set is also defined, is called JAVA bytecode here. At JAVA, on-the-fly compilers are also known that convert the bytecode into machine code during execution and thus achieve very high efficiency. The security concept from JAVA, also called 'sandbox', also allows no privileges to be granted to the JAVA program, so that spying on the workers' computer is prevented. Since the original identifiers are no longer available in P-code or JAVA bytecode, but only numbered variables, it takes more effort to recompile this program. This also leads to the fact that it is practically impossible to determine both the provider and the problem dealt with by them, together with a sufficient amount of data.

With P-code or bytecode interpreters in particular, the problem of performance evaluation is relatively simple in that the number of P-code or bytecode commands executed is counted and billed. This is even with 'on-the-fly' com- pilers possible, even if this leads to a slight reduction in performance.

One of the simplest workers therefore consists of a constantly or time-controlled or event-controlled program, e.g. a screen saver that fetches a URL from the intermediary, then fetches and formats the HTML file designated with it. The HTML file receives JAVA or JAVAscript 'applets', which are then executed. The results of the program or scripts are then sent to the provider as an HTML form using the intermediary's proxy function.

Instead of filters that always complete a job completely, solutions can also be provided in which a partially processed job is queued again and processed by the next worker. These are also known under the term 'agents'. There are two variants here: firstly, fixed applications in which the data format is selected so that an intermediate status is always saved. The diagonalization of a matrix can be used as an example, the processing of which consists of a chain of matrices that come closer and closer to the result and finally reaches it. Another variant, also referred to as 'snapshot', stores the values of the program variables together with the program and can therefore resume execution. However, this version requires quite a bit of memory to store the intermediate state.

It is therefore a method of using free computing power, in which an intermediary mediates orders and has them processed several times for security purposes.

Claims

claims

1. A method for using computing power in a network, in which an intermediary exchanges messages with both providers and with several workers, which run on separate computers, with the steps:

* a provider creates an order, preferably by splitting a task into independent parts, * the provider sends the order to the intermediary,

* the mediator receives a request from a worker,

* the mediator sends the worker the order

* the worker processes the order according to a method coded in the order, with a result being obtained,

* the worker delivers the result to the mediator,

* the mediator forwards the result to the provider.

2. The method according to the preceding claim, wherein the mediator queues orders or requests.

3. The method according to the preceding claims, wherein the mediator has certain orders processed by at least two different workers redundantly and compares the results.

4. The method according to the preceding claim, wherein the provider specifies the minimum number of redundant processing on his behalf.

5. The method of claim 3 or 4, wherein the agent determines a redundant processing of the order by a random selection.

6. The method according to claim 1, wherein the provider prescribes the planned effort or the maximum dwell time for each order and the worker informs the agent of the effort used with the result.

7. The method according to the preceding claim, wherein the mediator queues orders or inquiries, has certain orders processed by at least two different workers redundantly, compares the expenditure used and calculates the smaller of the two by the provider.

8. The method according to the preceding claim, wherein the mediator correlates the costs of the same orders with predetermined properties of the workers and thus can estimate the relative performance of the workers in advance.

9. The method according to the preceding claim, wherein the mediator normalizes the reported effort of redundant results on the basis of the correlation results and rejects results whose standardized effort lies above that of the other processing according to a predetermined limit.

10. The method according to any one of the preceding claims, wherein in each order contain a maximum processing time after which the results are considered to be without performance.

11. The method according to any one of the preceding claims, wherein a short processing time increases the coefficient of performance.

12. Mediator for performing one of the methods according to one of the preceding claims.