boinc/doc/client_fsm.html

48 lines
1.6 KiB
HTML

<h2>Core client: FSM structure</h2>
<p>
The core client can perform many activities
(file transfers, computations, RPCs to scheduling servers)
in parallel.
To manage this parallelism, the core client is
structures as a number of <b>finite-state machines</b> (FSM).
For example, an HTTP transaction is represented by an FSM
whose states might include:
<ul>
<li> Waiting for connection establishment.
<li> Waiting to send request header.
<li> Waiting to send send request body.
<li> Waiting for reply header.
<li> Waiting for reply body.
<li> Finished.
</ul>
<p>
FSMs of a particular type are managed by an <b>FSM container</b>.
Each FSM container manages a set of FSMs,
and provides a <b>poll()</b> function for
detecting and performing state transitions.
These functions are nonblocking.
<p>
The core client uses the following FSM types:
<ul>
<li><b>NET_XFER</b> (container: <b>NET_XFER_SET</b>).
Each instance represents a network connection,
for which data is being transferred to/from memory or a disk file.
The <b>poll()</b> function uses <b>select()</b>
to manage the FSM without blocking.
<li><b>HTTP_OP</b> (container: <b>HTTP_OP_SET</b>).
Each instance represents an HTTP operation
(GET, PUT or POST).
<li><b>FILE_XFER</b> (container: <b>FILE_XFER_SET</b>).
Each instance represents a file transfer (upload or download) in progress.
<li><b>ACTIVE_TASK</b> (container: <b>ACTIVE_TASK_SET</b>).
Each instance represents a running application.
</ul>
<p>
An FSM may be implemented using other FSMs;
for example, FILE_XFER is implemented using HTTP_OP,
which in turn is implemented using NET_XFER.