[omniORB] OmniORB behaviour with firewalls

[Sai-Lai Lo]

I suspect what the firewall does is just to drop the packets after 5 or 6
minutes. What an odd firewall policy! As far as tcp is concern, it just
see no ACK but not a disconnection. Until tcp finally timeout, which will
be a long time, the ORB runtime will not see a disconnection.

In Bruce's case, when BOA init is called, a passive socket is created and
listen() is called. From then on, any connect request that comes in will be
queued on the socket until accept() is called, which is done when
impl_is_ready() is called. The other end will be told the connection has
succeeded. Therefore, if BOA init is called but not impl_is_ready(), the
client side sees the connection successfully established but no one is
listening.

I agree it is undesirable for the clients to hang indefinitely in these
situations. In fact, if the outgoing scavenger is enabled, the stuck
connections will be shutdown in some cases, e.g. if the client has not finished
sending the request to the server. This will deal with the case Bruce has
problem with.  However, if the client has already sent the request, the
connection is allowed to stay on indefinitely.

It seems to me what is needed is a timeout value that can be set for a call
to complete. If the value has been exceeded, the communication is considered a
failure and COMM_FAILURE will be thrown. The timeout is the sum of the time
to send out the request and the time for the reply to come back. It is not
simple to choose an appropriate value for this timeout. Setting this value
too high would not be particularly useful. Setting this value too low may
upset some applications which are designed to wait patiently for the
computation to finish on the server.

The new connection management code in the post-2.8.0 releases already have
the option to implement this. Perhaps I'll put this feature in before the
2.8.0 final. I'm almost ready to put out 2.8.0pre2. May be I'll add this
feature to pre2 so as to give this a bit of time for testing.

Sai-Lai



>>>>> Eric Dumas writes:

> 	We meet currently a problem probably caused by a firewall.
> Here is the architecture:

> ----------                          ----------
> Component1| <----> Firewall <----> |Component2
> ----------                          ----------

> 	The firewall has been configured to allow Corba
> communications. However... the firewall will cut (disconnect) socket
> connection based on a timeout (5 or 6 minutes). The timeout is not
> based on an activity status... but on a life time of the socket.

> 	In some conditions (when performing a Corba call after the
> timeout, or waiting for the answer from Component2), Component1
> blocks. It may come from the omniORB... does omniORB check a 
> socket is still alived when sending data? Has anybody meet this
> kind of problem?


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