[omniORB] Why tcpSocketStrand::ll_recv blocking?

[Sai-Lai Lo]

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

> Isn't it better to use asynchronous sockets?
> Because I write a program with MFC using asynchronous sockets and I cut=
 off=20
> the connection and recv() fails and returns after a while.
> I think this way gives more control, isn't it?

For simple single threaded applications, do a select with timeout serves
the purpose. You still have to pick the right timeout value. Moreover, if
you have to cater for the case where you have to do multiple select/recv =
to
get the whole message, to do this right you have to recalculate the
remaining timeout value every time you are about to go into select.

omniORB 2.8.0 uses a more sophisticated scheme which I believe simplify
and reduce the overhead of timer management in a multithreaded
environment. The end result as seen by the application is the same.

Sai-Lai


> And I am trying to download omniOrb 2.8.0 and server fails with time ou=
t. Is=20
> there a problem at the server ?

>> From: Sai-Lai Lo <S.Lo@uk.research.att.com>
>> To: "Ceyhun =D6ZG=DCN" <ceyhun_ozgun@hotmail.com>
>> CC: omniorb-list@uk.research.att.com
>> Subject: Re: [omniORB] Why tcpSocketStrand::ll_recv blocking?
>> Date: 22 Nov 1999 12:32:47 +0000
>>=20
>> Ceyhun,
>>=20
>> 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 timer=
s in
>> 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 patient=
ly
>> try and wait until the connection comes back. During this time, any us=
er
>> space process doing a recv() will just block until some stuff comes in.
>>=20
>> If you are using omniORB 2.8.0, there is already a call timeout mechan=
ism
>> 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 adju=
sted
>> using the omniORB API. You should consult the user guide for the detai=
ls.
>> 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 t=
here
>> is any jitter in the network or at the server end.
>>=20


--=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