Re: Deconnection detection.

[dthompson characterlink net (Darrin Thompson)]

If you have time requirements that are this stringent, you probably 
should be using an ORB built with those kind of requirements in mind. TAO 
is an example of these that is open enough for most people. ORBit is 
quick and light, but introducing a time requirement on a corner case like 
what you have described is the domain of big fat bloated ORBs. Again, 
look into the capabilities of TAO.

Darrin

On 11/13/00, 11:37:13 AM, jean-paul roumian <jp roumian mobileway com> 
wrote regarding Deconnection detection.:


> Hello,

> When I use the 'echo-client/server ' from examples in ORBit source,
> if the echo-server is killed with KILL signal, the echo-client is
> hanging. ( on a select call
> in connection.c, giop_check_connections, block_for_reply is TRUE).

> It's very annoing from my point of view . (our softwares use connection
> timeouts, and retry mecanisms)

> I've found in the orbit-list archives about timeouts, and I 've
> concluded that: (correct me if I'm wrong)

> *  IIOP is built over TCP, so no deconnection detection (SO_KEEPALIVE is

> not flexible enough (no per-connection timeout,  not well-implemented
> every TCP stack,...)).
> * only a noop message implemented on a higher layer can acheive this.

> * Is it a bad thing to set the select timeout by an orbit-specific api
> call, and to implement a "NOOP" message mecanism (under,inside or over
> the IIOP layer ?). (I' don't masterise IIOP specs...)
> * Can the exception raised say precisely "connection tlmeout", not just
> comm failure ?

> Thanks.

> ¢¶â¶X¬¶f¢–)à–+-¢¶â¶X¬¶        è™ê+‚m§ÿæj)`ž‰ž¢¸?™¨¥™©ÿ–+-ŠwèþŠÛŠÙb