[omniORB] multiple profiles IOR

[Sai-Lai Lo]

Renzo,

Before GIOP 1.2, although one can put multiple IIOP profiles into an IOR,
there is no precise specification on what the client should do with the
multiple profiles. In other words, the client could just pick one at random
or even always pick the first one.

With GIOP 1.2, there is now an addition component tag within an IIOP
profile to encode additional IP addresses. Also, the client is suppose to
look at all these alternatives and try them until it can connect to the
server. However, it is not specified what the client should do when an
existing connection is broken. My intepretation is the client should try
the address that it last use, if that fails tries all the alternative
addresses until it can successfully reconnect. Is that the behaviour you
want for your purpose?

One aspect the GIOP 1.2 didn't specify is what order the alternative IP
addresses are tried. The order could be important to fault tolerance.
A colleague of mine told me that the new CORBA fault tolerant spec defines
an order in which alternative addresses are tried.

The good news is that the new GIOP 1.2 implementation in omniORB will
support multiple IP addresses. It is just that not all the features I want to
complete is done yet. At the moment, the implementation stay as a separate
development branch taken from omniORB 2.8. When it is ready, it will be
merged to omniORB 3. If you are interested to have a look, you can go to
our cvs server and checkout the omni2_9_develop branch. (By the way, please
send any queries regarding that branch to me directly and not to the list as
the branch is more a work in progress than a public release.)

The current status of the GIOP 1.2 implementation is:

1. GIOP 1.2 implementation is finished and I have received reports that it
   interoperate with Visibroker 4 beta (although it uncovers a couple of
   protocol violations in visi).

2. Firewall navigation via GIOP proxy works. (For those interested, there
   is now a spec for doing CORBA calls through firewalls via a so-called
   GIOP proxy.)

I am currently doing more extensive testing on the 1.2 implementation to make
sure that it is robust enough to handle misbehaving clients.

After that, here is the list of things to do before the work is done:

1. Handle multiple IP addresses in IOR. The ORB can parse such IOR but does
   not make use of the information yet.

2. Support SSL.

3. Support portable interceptors.

4. Support code set conversion, wchar and wstring

5. Support Bi-directional GIOP.

My current view is that the new GIOP implementation, even though it
supports the latest GIOP protocol revision, does not provide our users any
noticable benefit until we have at least item  1-4 finished. It shouldn't
take too long to do the work as most of the ground work is done.

I think item 1 is what you are looking for. Give us some time and we'll get
there.

Sai-Lai


>>>>> Renzo Tomaselli writes:

>         the subject is dangling around since sometime, but I could not read
> any definitive answer so far. So I kindly ask you, OmniORB developers,
> whether and how we can have OmniORB generating multiple profiles IORs for
> different IP addresses.
> I know it works for multiple ports through repeated BOA initialization, but
> how about multiple hosts (not necessarily matching locally available IP
> addresses)?
> This point is fundamental for designing implementation repositories and
> their forward management.


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