[omniORB] UDP/other protocols
Boris Khanales
boris@imagine-sw.com
Tue, 13 Jun 2000 09:01:53 -0400 (EDT)
What about POA specifications?
> Date: Tue, 13 Jun 2000 08:23:42 +0200
> From: "Haarek Ryeng" <Haarek.Ryeng@datarespons.no>
> X-Accept-Language: en
> To: omnilist <omniorb-list@uk.research.att.com>
> Subject: Re: [omniORB] UDP/other protocols
> X-Converted-To-Plain-Text: from multipart/mixed by demime 0.97b
> X-Converted-To-Plain-Text: Alternative section used was text/plain
> X-Loop: omniorb-list@uk.research.att.com
>
> 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]
Boris Khanales
Imagine Software
(212) 317 7632