[omniORB] Why tcpSocketStrand::ll_recv blocking?

[Sai-Lai Lo]

Ceyhun,

One point you have to bear in mind is that TCP/IP tries very hard to
deliver bits reliably to the other end. For this reason, various timers i=
n
the TCP stack have very long timeout period. This may not be what you
expect. You cut the network condition, the TCP stack will just patiently
try and wait until the connection comes back. During this time, any user
space process doing a recv() will just block until some stuff comes in.

If you are using omniORB 2.8.0, there is already a call timeout mechanism
to cause the ORB to throw a COMM_FAILURE if a remote invocation cannot
complete within a period of time. The actual timeout value can be adjuste=
d
using the omniORB API. You should consult the user guide for the details.
The timeout value is default to 1-2 minutes. Remember, if you set this
value to low, you may end up timeout remote calls unnecessarily when ther=
e
is any jitter in the network or at the server end.

Sai-Lai

>>>>> Ceyhun =D6ZG=DCN writes:

> Hi!
> I have a question.My platform specifications:
> WinNT 4.0 sp4, Visual C++ 6.0.
> When the program entered into the tcpSocketStrand::ll_recv function,
> I cut the network connection and expect the function return in a define=
d=20
> timeout period or by throwing an exception. Function does not continue =
even=20
> the network comes out and blocks forever. Please tell me a reasonable w=
ay to=20
> get out of this.
> Thanks!



--=20
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.c=
om=20
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND