The argument serverPoolName identifies the collection of servers
that are to support the new Byzantine fault-tolerant transaction session.
A CreateReplicasOnServers object is created to perform the setup.
The queryData argument contains the parsed parameters from the
HTTP request (processed by the parseHTTPformData() function). The
requestData argument is the tokenized HTTP request.
The options argument is a set of environment variables, typically
used for server-side-include processing (e.g., HTTP_SSIprocessor). The
page needs to be sent to the replyDest object by sending it a
Key elements of the request are obtained from the HTTP query data
made available in the queryData argument.
Indicates the type of the new transaction. The specified name
is used to determine the name of the implementation class and must
have been previously registered by a RegisterReplicaHTTPclass
Indicates the page to which the remote client browser should be
optional parameter that indicate the number of simultaneous faults
to be tolerated. It defaults to 1 and must be assigned a positive value.
The number of servers required is 2 * maxFaults + 1.
optional parameter which indicates the maximum number of
initial faults that can be tolerated at the time the session is
created. Valid values are between 0 and the value of maxFaults.
It defaults to its maximum permissible value (i.e., maxFaults
if minReliability is 2 or else 3 * maxFaults
if minReliability is 0), which maintains the correctness
guarantees asserted by Byzantine fault-tolerance or merely best-effort.
optional parameter that permits creation of a session with limited
fault-tolerance semantics. It defaults to a value of 2, which indicates
Byzantine fault-tolerance. If set to 0, best-effort reliability will be
performed if there are too many inital faults, which make it impossible
to establish a Byzantine fault-tolerant session. In such a situation,
all activity will be performed on a single server and the correctness
guarantees provided by Byzantine fault-tolerance cannot be assurred.
This is a significant negative, but it may outweigh the alternative of
denying service in the presence of too many faults even though at least one
system remains operational and capable of performing transactions.