2003-05-06 21:43:26 +00:00
|
|
|
<body bgcolor=ffffff>
|
2002-09-10 17:04:05 +00:00
|
|
|
<title>Data server protocol</title>
|
|
|
|
|
|
|
|
<h2>Data server protocol</h2>
|
|
|
|
|
2002-12-02 04:29:40 +00:00
|
|
|
Core client communicate with data servers using HTTP.
|
|
|
|
A data server is typically implemented using
|
|
|
|
a web server together with a BOINC-supplied CGI program,
|
|
|
|
<b>file_upload_handler</b>.
|
2002-09-10 17:04:05 +00:00
|
|
|
|
|
|
|
<h3>Download</h3>
|
|
|
|
<p>
|
2002-12-02 04:29:40 +00:00
|
|
|
File download is done by a GET request
|
|
|
|
to a URL from the FILE_INFO element.
|
|
|
|
The file offset, if any, is given in <b>Range:</b> attribute
|
|
|
|
of the HTTP header.
|
2002-09-10 17:04:05 +00:00
|
|
|
|
|
|
|
<h3>Upload</h3>
|
|
|
|
<p>
|
|
|
|
File upload is done using POST operations to a CGI program.
|
|
|
|
A security mechanism prevents unauthorized
|
|
|
|
upload of large amounts of data to the server.
|
|
|
|
Two RPC operations are used.
|
|
|
|
<p>
|
|
|
|
<b>1) Get file size</b>
|
|
|
|
<p>
|
|
|
|
The request message has the form:
|
|
|
|
<pre>
|
2002-12-02 04:29:40 +00:00
|
|
|
<data_server_request>
|
|
|
|
<core_client_major_version>1</core_client_major_version>
|
|
|
|
<core_client_minor_version>1</core_client_minor_version>
|
|
|
|
<get_file_size>filename</get_file_size>
|
|
|
|
</data_server_request>
|
2002-09-10 17:04:05 +00:00
|
|
|
</pre>
|
|
|
|
|
|
|
|
<p>
|
|
|
|
The reply message has the form:
|
|
|
|
<pre>
|
2002-12-02 04:29:40 +00:00
|
|
|
<data_server_reply>
|
|
|
|
<status>x</status>
|
|
|
|
[ <message>text</message>
|
|
|
|
| <file_size>nbytes</file_size> ]
|
|
|
|
</data_server_reply>
|
2002-09-10 17:04:05 +00:00
|
|
|
</pre>
|
2003-05-06 21:43:26 +00:00
|
|
|
Status is
|
|
|
|
<ul>
|
|
|
|
<li> 0 on success.
|
|
|
|
Nbytes is 0 if the file doesn't exist.
|
|
|
|
<li> 1 on transient error.
|
|
|
|
The client should try another data server, or try this one later.
|
|
|
|
<li> -1 on permanent error.
|
|
|
|
The client should give up on the result.
|
|
|
|
</ul>
|
|
|
|
In the error cases, the <file_size> element is omitted
|
|
|
|
and the <message> element gives an explanation.
|
2002-09-10 17:04:05 +00:00
|
|
|
<p>
|
|
|
|
<b>2) Upload file</b>
|
|
|
|
<p>
|
|
|
|
Request message format:
|
|
|
|
<pre>
|
2002-12-02 04:29:40 +00:00
|
|
|
<data_server_request>
|
|
|
|
<core_client_major_version>1</core_client_major_version>
|
|
|
|
<core_client_minor_version>1</core_client_minor_version>
|
|
|
|
<file_upload>
|
2002-09-10 17:04:05 +00:00
|
|
|
<file_info>
|
|
|
|
...
|
|
|
|
<xml_signature>
|
|
|
|
...
|
|
|
|
</xml_signature>
|
|
|
|
</file_info>
|
|
|
|
<nbytes>x</nbytes>
|
|
|
|
<offset>x</offset>
|
|
|
|
<data>
|
2003-05-06 21:43:26 +00:00
|
|
|
... (nbytes bytes of data; may include non-ASCII data)
|
2002-12-02 04:29:40 +00:00
|
|
|
</data>
|
2002-09-10 17:04:05 +00:00
|
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
The <file_info> element is the exact text sent from the
|
|
|
|
scheduling server to the client.
|
|
|
|
It includes a signature based on the project's file upload
|
|
|
|
authentication key pair.
|
|
|
|
<nbytes> is the amount of data being uploaded.
|
|
|
|
<offset> is the offset within the file.
|
|
|
|
<p>
|
|
|
|
Reply message format:
|
|
|
|
<pre>
|
2002-12-02 04:29:40 +00:00
|
|
|
<data_server_reply>
|
|
|
|
<status>x</status>
|
2003-05-06 21:43:26 +00:00
|
|
|
<message>text</message>
|
2002-12-02 04:29:40 +00:00
|
|
|
</data_server_reply>
|
2002-09-10 17:04:05 +00:00
|
|
|
</pre>
|
2003-05-06 21:43:26 +00:00
|
|
|
Status is
|
|
|
|
<ul>
|
|
|
|
<li> 0 on success.
|
|
|
|
<li> 1 on transient error.
|
|
|
|
The client should try another data server, or try this one later.
|
|
|
|
<li> -1 on permanent error.
|
|
|
|
The client should give up on the result.
|
|
|
|
</ul>
|
|
|
|
In the error cases, the <message> element gives an explanation.
|
|
|
|
<p>
|
|
|
|
TODO: if there's an error in the header
|
|
|
|
(bad signature, or file is too large)
|
|
|
|
the client should learn this without actually uploading the file.
|