22.15 Router Administration

   One basic function of a Router is to forward a request to another Router, which is “closer? to the eventual target of a client’s original request. In terms of the relationship between these two routers, the first Router can be thought of as the “source Router,? and the second can be called the “destination Router.? In the case where the network is partitioned or the destination Router has temporarily or permanently become unavailable, the source Router will be unable to forward its message. When this occurs, the Router must determine when and how to retry the request to the destination Router.

   To enable scalable networks of routers, a RouterAdmin interface has been specified. The interface is defined mainly for the purpose of avoiding the non-scaling scenario where a source Router has no choice but to consume network resources by continuously “pinging? its destination Router.

   This problem is analogous to the one faced by the target router when attempting delivery of the request to the message’s target. Therefore, the mechanism specified here generically supports registrations of destination routers as well as actual target object references.

   module MessageRouting {

   typedef short RegistrationState; const RegistrationState NOT_REGISTERED = 0; const RegistrationState ACTIVE = 1; const RegistrationState SUSPENDED = 2;

   exception InvalidState{ RegistrationState registration_state; };

   valuetype RetryPolicy supports CORBA::Policy { };

   const CORBA::PolicyType IMMEDIATE_SUSPEND_POLICY_TYPE = 50;

   valuetype ImmediateSuspend : RetryPolicy { };

   const CORBA::PolicyType UNLIMITED_PING_POLICY_TYPE = 51; valuetype UnlimitedPing : RetryPolicy {

   public short max_backoffs;public float backoff_factor;public unsigned long base_interval_seconds;

   };

   const CORBA::PolicyType LIMITED_PING_POLICY_TYPE = 52;valuetype LimitedPing : UnlimitedPing {public unsigned long interval_limit;};

   const CORBA::PolicyType DECAY_POLICY_TYPE = 53;valuetype DecayPolicy supports CORBA::Policy {public unsigned long decay_seconds;};

   const CORBA::PolicyType RESUME_POLICY_TYPE = 54;valuetype ResumePolicy supports CORBA::Policy {public unsigned long resume_seconds;};

   interface RouterAdmin {

   void register_destination(in Object dest,in boolean is_router,in RetryPolicy retry,in DecayPolicy decay);

   void suspend_destination(in Object dest,in ResumePolicy resumption)

   raises (InvalidState);

   void resume_destination(in Object dest)raises (InvalidState);

   void unregister_destination(in Object dest)raises (InvalidState);

   };

   interface Router { readonly attribute RouterAdmin admin; }; };

   When a request arrives at a Router (source router) that must either be delivered directly to a target, or be forwarded on via another Router (destination router), that source router attempts to send the message. If the message send fails, the source router needs to decide when to retry the send.

   The following use of the RouterAdmin is intended for router-to-router administration:

1. A source router gets a request that should be sent to a destination router. Since the source router has no registration for that destination router, it attempts to send the message.

2. Upon receipt of the message, the destination router realizes that it has never registered back with the source router and calls back to the source router's RouterAdmin (independent of the processing of the message - this is purely an optional administrative request to avoid poor routing behavior in the future). By calling back to the RouterAdmin, the destination router registers itself with its desired retry policy and decay policy for future messages. On subsequent messages, the destination router knows that it has already registered and need perform no administrative processing at this step.

3. At some time, the destination router knows it is being separated from the network. This case is termed “graceful disconnection.?

• The destination router notifies the source router that the registration should be suspended. • Upon subsequent requests, the source router consults its list of registrations. Since the destination router is currently SUSPENDED, no send is attempted (depending on the ResumePolicy at the time of suspension). • At some later time, the destination router becomes reconnected. It resumes its registration and can now receive stored (and later) messages.

4. At some time, the destination router becomes disconnected without any advanced warning (it may not know that it is disconnected). This case is termed “unexpected disconnection.?

• Upon subsequent requests, the source router consults its list of registrations. Since the destination router is currently ACTIVE, a send is attempted. When the send fails, the source router follows its RetryPolicy and keeps pinging until the RetryPolicy indicates the registration should be suspended (immediately if the RetryPolicy is ImmediateSuspend or never if the RetryPolicy is UnlimitedPing). • At some time, the destination router becomes reconnected. If the source router discovers this due to pinging, the pending requests can now be delivered. If the source router has SUSPENDED the registration or is in the midst of the interval between pings when the destination router re-registers itself, the registration can immediately be set to an ACTIVE state and pending requests can be sent to the destination router.

   The “target router? is the one that synchronously delivers requests to the target. The RouterAdmin is also used for the administration of policies that determine when this target router will actually attempt to deliver its request. A target’s use of this interface is very similar to the way it is used for router-to-router administration described above. The analogous scenarios are re-described here for clarity:

1. An object instance is activated with support for TII. Since the target is now ready to receive requests, it is registered with some router’s RouterAdmin with the target’s desired retry policy and decay policy. Typically, a reference to this router will also be contained in a MessageRouting::TAG_MESSAGE_ROUTERS component of the target’s object reference.

2. A router gets a request that it can deliver directly to the target (therefore this router is considered a “target router?). Since the target router has a registration for that object, it attempts to invoke the request.

3. At some time, the target knows it is being separated from the network. This case is termed “graceful disconnection.?

• The target notifies the target router that the registration should be suspended. • Upon subsequent requests, the target router consults its list of registrations. Since the target is currently SUSPENDED, no invocation is attempted (depending on the ResumePolicy at the time of suspension). • At some later time, the target becomes reconnected. It resumes its registration and can now receive stored (and later) requests.

4. At some time, the target becomes disconnected without any advanced warning (it may not know that it is disconnected). This case is termed “unexpected disconnection.?

• Upon subsequent requests, the target router consults its list of registrations. Since the target is currently ACTIVE, an invocation is attempted. When this invocation fails, the target router follows its RetryPolicy and keeps pinging until the RetryPolicy indicates the registration should be suspended (immediately if the RetryPolicy is ImmediateSuspend or never if the RetryPolicy is UnlimitedPing). • At some time, the target once again becomes available. If the target router discovers this due to pinging, the pending requests can now be delivered. If the target router has SUSPENDED the registration or is in the midst of the interval between pings when the target re-registers itself, the registration can immediately be set to an ACTIVE state and pending requests can be invoked on the target.