Archived
This forum has been archived. Please start a new discussion on GitHub.
AMI calls and congestion
in Help Center
Hi,
I have a question about asynchronous calls over TCP. Is there any possibility for asynchronous call to block. I am thinking about congestion situations. Does ICE controll (in any way) client's sending rate and blocks in case of congestion (or maybe when transport layer buffer is full as is with oneway invocations).
Resuming is there any way to tell that there is a congestion? Finally, does ami invocation works as oneway in the sence that message is immediatelly written into transport layer buffer or is it buffered somewhere in ICE runtime.
Thanks for help.
Tom.
I have a question about asynchronous calls over TCP. Is there any possibility for asynchronous call to block. I am thinking about congestion situations. Does ICE controll (in any way) client's sending rate and blocks in case of congestion (or maybe when transport layer buffer is full as is with oneway invocations).
Resuming is there any way to tell that there is a congestion? Finally, does ami invocation works as oneway in the sence that message is immediatelly written into transport layer buffer or is it buffered somewhere in ICE runtime.
Thanks for help.
Tom.
0
Comments
-
With Ice 3.2.1 AMI requests can block if the transport blocks. We've written about this many times in the past in our newsletter, and you can read this related FAQ http://www.zeroc.com/faq/onewaysBlock.html.
Starting with Ice 3.3 this restriction will be removed and AMI & async oneway calls will never block the caller. There will be no Ice provided flow-control, however. If the application queues AMI or oneway messages indefinitely then it will eventually exhaust all memory. It is up to the application to ensure that this does not occur through appropriate use of the Ice provided callbacks.0
