Changes of Simple Parallel Exec from #15 to #16

Changed lines at line 101
[Input filename]* (filename can be "STDIN")
Content=<<ENDOFCONTENT
real file content here (ASCII)
ENDOFCONTENT
[Result filename]+ (filename can be "STDOUT")
Name=resultname
{code}
* the * behinds the section means there can be _zero_ or more sections
* the + behinds the section means there can be _one_ or more sections
1.1 Task completed
- Successful: POST \http://master/complete?sessionid=SESSIONID&ticket=TICKET
{code:none}
[Result]+
Name=resultname
Content=<<ENDOFCONTENT
file content here (ASCII)
ENDOFCONTENT
{code}
- Failed: GET \http://master/failed?sessionid=SESSIONID&ticket=TICKET
- Reply Fail due to wrong session id: 403 (Forbidden)
- Reply Otherwise:  200 OK
* binary content is not supported
1 Implementation Details
1.1 Configuation and Files
- Server config: TODO describe
- Parameter file: csv file, cells seperated with |, parameter names in the headline and every following line contains one parameter set. All lines have to have the same amount of cells like the headline!
- Specification of worker: Command line: a perl syntax string with parameter Variables for the parameters; Input files: Name of the file and parameter name to write in.
- Result specification: A result consists of a list of name - value pairs. Where name specifies the name of the particular output and value decides where the output comes from. For example myoutput="stdout", myfileoutput="out.txt".
- Validation: standart implementations are provided and a custom implementation can be provided by the user as a perl function. A validation function gets the result of the worker and returns success or failture.
- Collection: standart implementations are provided and a custom implementation can be provided by the user as a perl function. A collection function gets task description (number, parameters set) and the result of the worker and can do whatever it wants with it (usually writes in a file). 
1.1 NFS awareness
The problem is, that if some slaves share files via NFS or another network filesystem it could happen that
different clients overwrite their data. Basically there are three points where it occurs:
1. the client is copied
1. the client fetches the worker
1. the worker writes its data to a file.
Solutions:
1. a) start and copy clients in serial (very slow)  b) copy just one client at time, but start in parallel (fast on NFS, slow otherwise)
1. before fetching the worker the client creates a .lock file. The other clients check the existance and wait for the worker. 
1. every worker is started in a separate directory, given by the session id and the ticket number
1.1 Error detection
Remote shell command (ssh) termination code:
[Input filename]*
Content=single-line file content 
or
Content= <<EOT
multi-line file content here (ASCII)
EOT
[Result name]+ 
File=filename
{code}
* the * behinds the section means there can be _zero_ or more sections
* the + behinds the section means there can be _one_ or more sections
1.1 Task completed
- Successful: POST \http://master/completed?sessionid=SESSIONID&ticket=TICKET
{code:none}
[Result name]+
Content= single-line file content
or
Content= <<EOT
multi-line file content here (ASCII)
EOT
{code}
- Failed: GET \http://master/failed?sessionid=SESSIONID&ticket=TICKET
- Reply Fail due to wrong session id: 403 (Forbidden)
- Reply Otherwise:  204 (No Content)
* binary content is not supported
1 Implementation Details
1.1 Configuation and Files
- Server config: See __server.sample.conf__ in the side bar.
- Task file: __tasks.csv__ : csv file, cells seperated with |, parameter names in the headline and every following line contains one parameter set. All lines have to have the same amount of cells like the headline!
{code:none}
string|counter
"eins"|1
"zwei"|2
{code}
- Worker config: See __worker.sample.conf__ in the side bar.
- Input specification: The input consists of the command line and one ore more files. In the example above the parameter "counter" is passed as an commandline argument and the parameter "string" is written in the file input.file. This file is used as standart input for the worker. One can specify other files as well, in case the worker reads them. 
- Result specification: A result has a name and filename where to get the result values from.  In the above example one result is calles "Result" and it comes from the file result.file, which is the standart output of the worker. The second result is calles "Output" and is read from output.file. If the worker doesn't write to this file the result will be empty. 
- Validation: standart implementations are provided and a custom implementation can be provided by the user as a perl function. A validation function gets the result of the worker and returns success or failture. (See Validate.pm)
- Collection: standart implementations are provided and a custom implementation can be provided by the user as a perl function. A collection function gets task description (number, parameters set) and the result of the worker and can do whatever it wants with it (usually writes in a file). (See Collect.pm)
1.1 Server
- The server is implemented in perl. 
- Perl has no reasonable way to use shared memory in multiply threads. Since the program is written using perl objects and objects can't be shared I decided to make a __serial__ implementation first. 
- That means just one request can be responded at the time
- Consequences: slow start if there are many slaves; less suitable for very small tasks with large input/response data
1.1 NFS awareness
The problem is, that if some slaves share files via NFS or another network filesystem it could happen that
different clients overwrite their data. Basically there are three points where it occurs:
1. the client is copied
1. the client fetches the worker
1. the worker writes its data to a file.
Solutions:
1. a) start and copy clients in serial (very slow) (current implementation)  b) copy just one client at time, but start in parallel (fast on NFS, slow otherwise)
1. before fetching the worker the client creates a .lock file. The other clients check the existance and wait for the worker.
1. every worker is started in a separate directory, given by the session id and the ticket number
1.1 Error detection
* No client could be started
* Swarm: Remote shell command (ssh) termination code: