[omniORB] New features request

[Sai-Lai Lo]

>>>>> Cary O'Brien writes:

>> Cary O'Brien <cobrien@Radix.Net> said:
>> 
>> > 
>> > Someone was asking about new features a while back.  I've
>> > got two suggestions (in order of decreasing sanity) I'll
>> > throw out.
>> > 
>> > 1. Be able to specify the IP address that an ORB binds
>> >    to.  If you have a host on multiple lans, you may want some
>> >    services available from one lan and some services available
>> >    from another lan.   I guess this would be per-orb, and would
>> >    apply to both clients and servers.
>> > 
>> > 2. Be able to somehow control the IP address that gets incorporated
>> >    into the object reference that goes back to the client.  The goal
>> >    would be to be able to return, say, a firewall IP address to external
>> >    clients, and an internal IP address to local clients.
>> > 
>> You can already do #2.  I can't remember the correct command line arguments.  
>> Something like -ORBInitialHost.  If you look through the OmniOrb 
>> documentation, you should find something about it there.
>> 

> Correct, this is part of what I am after.  What I really want is
> run-time control, so the service would appear to be at different IP
> addresses depending on who is asking.

> If I have feature #1, I can sort of do this statically by running a couple
> of processes each bound to and replying from specific IP addresses, but
> it would be nice to have a single servant that can handle accesses from
> multiple ip addressing schemes.  (i.e. private vs public).

I can see what you are getting at. However, inserting a different IP
address into an object reference based on who is asking can be
confusing. Think about the situation where server A send the object
reference to B which is outside the firewall and B send the object
reference back to C which is inside the firewall. C cannot use the object
reference to contact A because the IP address is on the public network.

Now that I have disappointed you, here is how it is going to work in
omniORB 4:

1. You tell the ORB to insert as many IP addresses as you like into an object
   reference. This can also include, for instance, SSL address.
2. On the client side, the ORB refers to an application supplied
   configuration table which tells it:
    a) based on the destination IP address, which transport, i.e. plain or
       SSL, should be used.
    b) which IP subnet is "closer" and should be used if there are more 
       than one IP addresses to choose from.
    c) which IP subnet should definitely not be used because it is an
       unsafe network
    d) some other rules that I have not think of yet...
3. For an object reference with multiple IP addresses, the ORB then remove
   those that should not be used and sorted the rest according to the
   preferences listed in 2). For each invocation, it will try each of the
   addresses in turn until the operation succeed. 

Hope this information help. Soon omniORB 4 will be ready for testing. I'll
make an annoucement when it is so.

Regards,

Sai-Lai 

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