Encapsulate the flushing control parameters.
At several points, the ORB needs to flush data from a transport to the underlying I/O mechanisms. How this data is flushed depends on the context where the request is made, the ORB configuration and the application level policies in effect.
Some examples:
When idle, the ORB will want to send data on any socket that has
space available. In this case, the queue must be drained on a best-effort basis, without any blocking.
If the ORB is configured to handle nested upcalls, any two-way
request should block and push data to the underlying socket as fast as possible.
In the same use-case, but now with a timeout policy in
effect, the ORB will need to send the data use I/O operations with timeouts (as implemented by ACE::sendv()
When the ORB is configured to support nested upcalls, any two-way,
reliable oneway or similar should wait using the reactor or Leader-Follower implementation. While still respecting the timeout policies.
Instead of sprinkling if() statements throughput the critical path trying to determine how the I/O operations should be performed, we pass the information encapsulated in this class. The caller into the Transport object determines the right parameters to use, and the Transport object simply obeys those instructions.