Timeout for RPC call via TCP/IP

[Frank Franzoni]

Hello all,

We have developed an rpc server running as a service. The client connects to
this server via the ncacn_ip_tcp protocol sequence. When the network
connection is interrupted (for example the cable is removed) while the
client calls a rpc function it takes 20 seconds until the function is
returned with an error.
Where does this timeout come from (rpc, tcp/ip)? How can we shorten this
timeout?
RpcMgmtSetComTimeout does not work because the mininum timeout for Windows
XP is 120 seconds (RPC_C_BINDING_MIN_TIMEOUT), but the function is always
returned after 20 seconds.

Greetings Frank Franzoni

[Thore Karlsen [MVP DX]]

On Thu, 22 Jul 2004 15:03:29 +0200, "Frank Franzoni"

Post by Frank Franzoni
Hello all,
We have developed an rpc server running as a service. The client connects to
this server via the ncacn_ip_tcp protocol sequence. When the network
connection is interrupted (for example the cable is removed) while the
client calls a rpc function it takes 20 seconds until the function is
returned with an error.
Where does this timeout come from (rpc, tcp/ip)? How can we shorten this
timeout?
RpcMgmtSetComTimeout does not work because the mininum timeout for Windows
XP is 120 seconds (RPC_C_BINDING_MIN_TIMEOUT), but the function is always
returned after 20 seconds.

...

Try RpcBindingSetOption with RPC_C_OPT_CALL_TIMEOUT. I've only tested it
briefly, but it seems to work. (Only on XP, though.)

I can't believe timeouts and asynchronous calls weren't in RPC from the
beginning. It really only seems to be suitable for fast local networks,
at least if you need the clients to stay compatible with Win98.
Performance and reliability over slow networks has been extremely
disappointing for us.

[Frank Franzoni]

Hello Thore,

Post by Thore Karlsen [MVP DX]
Try RpcBindingSetOption with RPC_C_OPT_CALL_TIMEOUT. I've only tested it
briefly, but it seems to work. (Only on XP, though.)

Thanks for your quick answer.
I tried this option but it is behaving strangly. For the first rpc call it
still takes 20 seconds until the call is
returned with an error.
When the network is interrupted after the first successful rpc call, all
following calls are returned within the time set in the option.
I suspect that this 20 seconds timeout does not come from the rpc runtime
but from tcp/ip.
Do you have an idea where to shorten this 20 seconds?

Greeting Franzoni Frank

[Thore Karlsen [MVP DX]]

On Fri, 23 Jul 2004 09:07:23 +0200, "Frank Franzoni"

Post by Frank Franzoni

Post by Thore Karlsen [MVP DX]
Try RpcBindingSetOption with RPC_C_OPT_CALL_TIMEOUT. I've only tested it
briefly, but it seems to work. (Only on XP, though.)

Thanks for your quick answer.
I tried this option but it is behaving strangly. For the first rpc call it
still takes 20 seconds until the call is
returned with an error.
When the network is interrupted after the first successful rpc call, all
following calls are returned within the time set in the option.
I suspect that this 20 seconds timeout does not come from the rpc runtime
but from tcp/ip.
Do you have an idea where to shorten this 20 seconds?

...

It looks like the first RPC call is treated specially, and perhaps the
alternative code path doesn't respect the timeout. I tried looking at
the source code for the RPC implementation to see what was going on, but
it's too complex to get an overview quickly.

I'm not sure if there's a fix for this problem. I've searched for this
kind of information before (timeouts, call cancellation, asynchronous
calls), and there's precious little information about it apart from
MSDN. I get the impression very few people are using these facilities.
Or if they are, they must not be needing/seeking help online.

The lack of control you have over what's going on behind the scenes with
RPC is very frustrating, and if you expect to use it over faulty/slow
connections I would recommend (based on my experiences) that you at
least consider alternatives. Building a robust, responsive, and fault
tolerant application around RPC is extremely hard.

[Arkady Frenkel]

20c is default time for service to start , no connection to TCP/IP
Arkady

Post by Thore Karlsen [MVP DX]
On Fri, 23 Jul 2004 09:07:23 +0200, "Frank Franzoni"

Post by Frank Franzoni

Post by Thore Karlsen [MVP DX]
Try RpcBindingSetOption with RPC_C_OPT_CALL_TIMEOUT. I've only tested it
briefly, but it seems to work. (Only on XP, though.)

Thanks for your quick answer.
I tried this option but it is behaving strangly. For the first rpc call it
still takes 20 seconds until the call is
returned with an error.
When the network is interrupted after the first successful rpc call, all
following calls are returned within the time set in the option.
I suspect that this 20 seconds timeout does not come from the rpc runtime
but from tcp/ip.
Do you have an idea where to shorten this 20 seconds?

It looks like the first RPC call is treated specially, and perhaps the
alternative code path doesn't respect the timeout. I tried looking at
the source code for the RPC implementation to see what was going on, but
it's too complex to get an overview quickly.
I'm not sure if there's a fix for this problem. I've searched for this
kind of information before (timeouts, call cancellation, asynchronous
calls), and there's precious little information about it apart from
MSDN. I get the impression very few people are using these facilities.
Or if they are, they must not be needing/seeking help online.
The lack of control you have over what's going on behind the scenes with
RPC is very frustrating, and if you expect to use it over faulty/slow
connections I would recommend (based on my experiences) that you at
least consider alternatives. Building a robust, responsive, and fault
tolerant application around RPC is extremely hard.
--
Be seeing you.

...

[Arkady Frenkel]

Sorry , my answer not connected to question :)
Arkady

Post by Arkady Frenkel
20c is default time for service to start , no connection to TCP/IP
Arkady

Post by Thore Karlsen [MVP DX]
On Fri, 23 Jul 2004 09:07:23 +0200, "Frank Franzoni"

Post by Frank Franzoni

Post by Thore Karlsen [MVP DX]
Try RpcBindingSetOption with RPC_C_OPT_CALL_TIMEOUT. I've only tested

it

Post by Thore Karlsen [MVP DX]

Post by Frank Franzoni

Post by Thore Karlsen [MVP DX]
briefly, but it seems to work. (Only on XP, though.)

Thanks for your quick answer.
I tried this option but it is behaving strangly. For the first rpc call

it

Post by Thore Karlsen [MVP DX]

Post by Frank Franzoni
still takes 20 seconds until the call is
returned with an error.
When the network is interrupted after the first successful rpc call, all
following calls are returned within the time set in the option.
I suspect that this 20 seconds timeout does not come from the rpc runtime
but from tcp/ip.
Do you have an idea where to shorten this 20 seconds?

It looks like the first RPC call is treated specially, and perhaps the
alternative code path doesn't respect the timeout. I tried looking at
the source code for the RPC implementation to see what was going on, but
it's too complex to get an overview quickly.
I'm not sure if there's a fix for this problem. I've searched for this
kind of information before (timeouts, call cancellation, asynchronous
calls), and there's precious little information about it apart from
MSDN. I get the impression very few people are using these facilities.
Or if they are, they must not be needing/seeking help online.
The lack of control you have over what's going on behind the scenes with
RPC is very frustrating, and if you expect to use it over faulty/slow
connections I would recommend (based on my experiences) that you at
least consider alternatives. Building a robust, responsive, and fault
tolerant application around RPC is extremely hard.
--
Be seeing you.

...

[Greg Kapoustin [MSFT]]

If one is making a call to a dynamic endpoint, RPC runtime will first try to
resolve the endpoint with the endpoint mapper on the server. On Windows XP,
the call timeout will not affect this internal endpoint resolution call, so
that call can take longer to time out, as seems to happen in your case.
This problem should not exist on Windows Server 2003.

Additional information on this general area is available at:

http://msdn.microsoft.com/library/en-us/rpc/rpc/rpc_and_the_network.asp

Also, please note that the best way to handle possible communication
latencies on slow networks is to use async RPC.

Writing a solid RPC application that works well over slow or unreliable
networks is difficult, but this is largely due to the inherent complexity of
dealing with such networks. Writing a distributed application using sockets
for such networks will be even more challenging, since RPC shields users
from the low-level details of the underlying protocols.

Greg
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Post by Thore Karlsen [MVP DX]
On Fri, 23 Jul 2004 09:07:23 +0200, "Frank Franzoni"

Post by Frank Franzoni

Post by Thore Karlsen [MVP DX]
Try RpcBindingSetOption with RPC_C_OPT_CALL_TIMEOUT. I've only tested it
briefly, but it seems to work. (Only on XP, though.)

Thanks for your quick answer.
I tried this option but it is behaving strangly. For the first rpc call it
still takes 20 seconds until the call is
returned with an error.
When the network is interrupted after the first successful rpc call, all
following calls are returned within the time set in the option.
I suspect that this 20 seconds timeout does not come from the rpc runtime
but from tcp/ip.
Do you have an idea where to shorten this 20 seconds?

It looks like the first RPC call is treated specially, and perhaps the
alternative code path doesn't respect the timeout. I tried looking at
the source code for the RPC implementation to see what was going on, but
it's too complex to get an overview quickly.
I'm not sure if there's a fix for this problem. I've searched for this
kind of information before (timeouts, call cancellation, asynchronous
calls), and there's precious little information about it apart from
MSDN. I get the impression very few people are using these facilities.
Or if they are, they must not be needing/seeking help online.
The lack of control you have over what's going on behind the scenes with
RPC is very frustrating, and if you expect to use it over faulty/slow
connections I would recommend (based on my experiences) that you at
least consider alternatives. Building a robust, responsive, and fault
tolerant application around RPC is extremely hard.
--
Be seeing you.

...