[omniORB] UDP/other protocols

[Haarek Ryeng]

Sounds like an interesting project - wireless communication and all.

Well - OmniORB 2.8 and 3.0 supports timeout managing on a high level (see chapter
7.3 for 2.8 and ch. 8.3 for 3.0). It is possible to configure timeouts both for
the server's incomming calls, and for the clients outgoing calls. But mind you - I
think this is on a high level - i.e. there is a dedicated thread who scans
connection and checks them against their configured timeouts. This thread runs
with a configurable granularity.
The timeouts can be changed using the omniORB::callTimeOutPeriod()
call, or with the command line options -ORBclientCallTimeOutPeriod and
-ORBserverCallTimeOutPeriod.
Also - have look at: ORBinConScanPeriod, ORBoutConScanPeriod,
omniORB::idleConnectionScanPeriod()

To really be able to control your TCP/IP stack behavior on a low level (TCP
retries) you need to adjust timeout and retry-algorithms within this stack. This
is possible on some Operating Systems. If not, one could consider buying a third
party TCP/IP stack.
If the stack is configurable via an API, one could maybe hack some in the OmniORB
code to configure the stack the way you want (I'm on thin ice here ;-) ).

I don't think oneway operations do what you want. They still use TCP, they just
don't block your client code (correct me someone if I'm wrong).

If none of the above leads to success, I guess your down to plugg your own
protocols.

Hope these pointers helps.

mdavis@rwii.com wrote:

> I realize this response is well out of date, given the date this message was
> sent (over a yyear ago), but I am having some difficulties.
>
> I am working on a large project, and some factions are pushing for some of
> the data to be over UDP, so that there are no TCP retries, etc.  Basically,
> we have a network such that connections could drop out and return randomly
> based on any number of things, as it is over a radio-ethernet link to a
> mobile platform.  There may be a relay station between the mobile platform
> and the ultimate destination of the data.  The people pushing for UDP are
> doing so to avoid flodding the relay station with attempted retries as
> connection s come and go. I have been pushing to keep everything in TCP,
> and find other ways to deal with this issue.
>
> Does anyone have any suggestions about how to limit the number of TCP
> retries, or plug in a protocol that would avoid the retry problem?
>
> I know that ORBacus for Java supports a Timeout policy.  Also, I know we
> could use one-way requests.  Does this solve my problem, or does it hide the
> retries from me?  If it DOES solve my problem, does OmniORB 2.8 support a
> Timeout policy?  What about OnmiORB 3.0?
>
> At one point in the past, for another project with truly wierd goals, I
> implemented another protocol under OmniORB 2.7 that communicated to a single
> object over a serial line.  It was not pretty, and I would rather not do it
> again, but if that is the only way to get what I need, then I may have to do
> it again.  :(
>
> I appreciate any information that can be provided.
>
> > Gary D. Duzan (gdd0@gte.com)
> > Thu, 07 Jan 1999 09:10:32 -0500
> >
> >    Well, strictly speaking you can't do GIOP over a connectionless
> > transport since it is inherently connection-oriented, but not all
> > CORBA communication has to be GIOP-based.
> >
> >                                         Gary Duzan
> >                                         GTE Laboratories
> >
> > In Message <001601be39db$2e073d40$0500000a@cc702523-a.hwrd1.md.home.com> ,
> >    "Doug Anderson" <doug@clark.net> wrote:
> >
> > =>Hi,
> > =>
> > =>Sai Lai wrote:
> > =>>Unlike other ORBs, there is no way to insert a handler into omniORB2 to
> > get
> > =>>a callback when a connection is made or when it is broken. It is my
> > opinion
> > =>>that using the status of network connections to detect client failure is
> > =>>a poor way of doing the job and does not fit in very well with the CORBA
> > =>>framework. It is the job of the ORB to decide when is the best time to
> > =>>establish a connection and how many connections are necessary to
> > =>communicate
> > =>>with the server.
> > =>
> > =>Not to mention the fact that this would not work well in a connection-LESS
> > =>GIOP implementation, ala IIOP over UDP?? (if and when such a beast
> > =>becomes commonplace!)
> > =>
> > =>Doug
> > =>
> > =>
> > =>
> --
> Mike Davis           Real World Interface, a division of I.S. Robotics
> mdavis@rwii.com      http://www.rwii.com
> 603-532-6900 x215    fax : 603-532-6901

[demime 0.97b removed an attachment of type text/x-vcard which had a name of haarek.ryeng.vcf]