The RPC runtime allows server applications to specify the number of manager threads available to handle concurrent RPCs via the max_calls_exec parameter of the rpc_server_listen( ) routine. The runtime also allows applications to specify the number of unhandled calls that can be queued via the max_call_requests parameters of the rpc_server_use_*protseq*( ) routines. In theory, these two values should be set in conjunction, but in practice, the interpretation of the max_calls_requests parameter is highly dependent on protocol and implementation.
For example, in a connection-oriented protocol based on Berkeley sockets, the socket backlog - the number of connections which may be queued on a socket pending acceptance - typically has a value of five.
Portable applications should therefore not rely on max_calls_requests as anything more than a hint to the runtime about the number of queued calls desired. Note well that the max_call_requests parameter does not set the number of calls that can be handled concurrently. That is strictly a function of the number of call threads, as specified by max_calls_exec. The max_call_requests parameter simply specifies (as a hint) the number of calls that can be queued prior to being picked up by call threads.