The underlying MultiplexedMsgConnection is implemented using IO completion ports. As far as writing is concerned, an IOCP thread executes each time the last write has deemed to be completed, which really means that the TCP stack is ready for another async write to be issued in order to keep the send buffer filled.
However cxRmi uses a BufferedMessageWriter in order to support arbitrary buffering of messages in memory. It is therefore possible for a thread which makes many calls on the stub to consume more and more memory until system memory is exhausted (and the process begins to page fault). Even if that doesn't happen, buffering causes latency, and big buffers over a low bandwidth connection can mean very high latency.
It is therefore appropriate to throttle a "producer" of messages. If this is done during a call to a stub while the calling thread has locked resources, then we have the disadvantage that resources are locked while the thread blocks on I/O. It is better to throttle the producer with a different method call (see WaitProducer()), that can be made when it doesn't lock resources.