[omniORB] Small tweak for local object detection

[Chris Newbold]

On Thu, 2002-08-22 at 07:48, Duncan Grisby wrote:

> Unfortunately, there are some situations in which you do want to match
> on only one address. One example is where you issue a persistent
> object reference, quit, then come back with a different set of
> endpoints, but still including one you had before. In this case, you
> would still want to consider the old reference local.

Good point and, in fact, we are about to run into just that problem.
Perhaps there is a better way to handle our situation...?

For example, we've got two hosts, one is active and the other is a
hot-standby. Some subset of our objects (those required to provide
seamless service) are mirrored in the hot-standby; these objects all
have persistent object references.

With our "active address" scheme, we've really got two IORs for the two
redundant instances, each having two profiles. On host A, the IOR for
one of these objects looks something like this:

    key: "HelloWorld"
    profile 0: tcp: 1.1.1.1:<port>		// "active" address
    profile 1: tcp: x.x.x.x:<port>		// private address
    
On the hot-standby host B, the IOR for the same object looks like this:

    key: "HelloWorld"
    profile 0: tcp: 1.1.1.1:<port>		// "active" address
    profile 1: tcp: y.y.y.y:<port>		// private address

Clients have transport rules which force them to always use the special
"active" address when contacting the object.

Just to make things more complicated for ourselves, the redundant
instances of these objects talk directly to each other in order to
synchronize state. We achieve this by installing transport rules on the
server for "HelloWorld" which disallow use of the "active" address; thus
they can talk to each other via the private addresses.

Obviously we need to always use the same port for the profile with the
"active" address, since it must be a true persistent reference for
clients.

There is no need to use any particular port for the private profiles, so
we may allow that to float. In that case we'll need a more advanced
scheme for detecting local vs. remote. For example, we could examine
just the IP addresses and not the ports. So profile 0 would always match
(since it's persistent) but in order to differentiate the two possible
profile 1's (host A's vs. host B's) we'd need to match address but not
port...

So, any better ideas how to achieve the hot-standby functionality? The
basic requirement is that host A be able to vanish (as in the hardware
just suddenly goes *POOF!* and is no longer there) and that requests (on
persistent objects) be redirected to host B transparently to any client
(in particular, clients should not have to get new object references).

> I think the proper solution to this issue is to have some sort of
> address matching mask that allows you to specify which interfaces have
> to match for a reference to be considered local. It's too late to do

This seems like the right idea. Something along the lines of the client
and server transport rules would be nice.

-- 
====( Chris Newbold  <cnewbold@laurelnetworks.com>
)===========================
      Laurel Networks, Inc. voice: +1 412 809 4200 fax: +1 412 809 4201
"If you fool around with a thing for very long you will screw it up." 
--Murphy
-------------------------------------------------------------------------------