Issue 2592: Problem: Why is AssociationId a string? (incorba-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Section number: 4.2.1 Problem: Why is AssociationId a string? Should one explore the possibility of using a combination of values supplied by both the initator and responder. Strings do not seem to be the most scalable solution. Resolution: Revised Text: Why is AssociationId a string? Should one explore the possibility of Actions taken: April 1, 1999: received issue Discussion: End of Annotations:===== Issue: 9 Section number: 4.2.1 Problem: Why is AssociationId a string? Should one explore the possibility of using a combination of values supplied by both the initator and responder. Strings do not seem to be the most scalable solution. Proposed solution: Rationale: Date: Wed, 22 Sep 1999 19:15:46 +0100 From: Neill Jones Organization: Teltec DUC X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: incorba-ftf@omg.org, brennanr@Teltec.DCU.IE, jonesn@Teltec.DCU.IE Subject: Issue 2592 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Tpa!!G9b!!#(De9SdRd9 Hi all The current issue states that the Application Id being a string is not scalable. I believe it is scalable, but is undesirable, from an high-performance point of view. Since the gateway, to be commercially viable, has to be a high-performance system, this should be of concern to the design (that is the design should not prevent optimisations in the implementation even if it doesn't explicitly deal with those optimisations). Currently the application id is expected to be unique within the system, so a possible implementation could use the initiators IOR in string format. This plus some id for the object would be unique. Alternatives could include server ip address and a TCP/IP port number plus another id if there are multiple interfaces of the same type within the process, and then of course some id for the association. Either way you have an variable length id which would need to be stored using dynamic memory allocation. Although the cost of a string creation is not high in terms of time in a low performance system, it can be significant in a high-performance system. There is also the additional time required to find strings, and the creation of the id in the first place. And with a system which can allocate say 20000 dialogs simultaneously, and association ids of about 250 bytes (say with an IOR plus Id), this is 4 megs of memory just to store identifiers. The advantage of the application id being unique however, is that new associations can be implicitly created using the DialogFlowCtr set to BEGIN during a new call. This reduces the number of CORBA calls required to start an association by one, which at a millisecond a call is a valuable saving in a high performance system. A preferable alternative is one that preserves the creation of new dialog ids implicitly, but is also fixed in length, allowing pre-allocation of required memory for real-time efficiency and predicability. Proposed here is one solution to this. AssociationId -------------- Association Ids are a tuplet of type CORBA::long. struct AssociationId { unsigned long major; // incremented each explicit new association unsigned long minor; // incremented each implicit new association }; Starting an Association Explicitly ---------------------------------- At the beginning of an explicit dialogue (through the call new_association)the initiator creates a locally unique association id setting the explicit value to X, and the implicit to 0. The responder creates a corresponding association_id and passes that back to the initiator on the call. Then during one association, each call requires the initiator to send the RESPONDER's association id and vice versa. Since these are unique to the initiator and responder, the objects will be able to deal with the calls correctly. Required Changes to the IDL: interface TcUser:CosLifeCycle::LifeCycleObject { void new_association(in TcUser initiator, in AssociationId initiator_a_id, out AssociationId responder_a_id) raises(NoMoreAssociations); void new_association_with_dialogdata( in TcUser initiator, in AssociationId initiator_a_id, out AssociationId responder_a_id, in string protocol_version, in DialogUserData d_u_d) raises(NoMoreAssociations, InvalidParameter); readonly attribute TcContextSetting tc_context_setting; }; //end TcUser interface TcUserGenericFactory{ TcUser create_tc_userResponder( in ScopedName responder, in TcUser initiator, in AssociationId initiator_a_id, out AssociationId responder_a_id, in TcContextSetting tc_context_setting) raises(CosLifeCycle::NoFactory, NoMoreAssociations, UnsupportedTcContext); TcUser create_tc_userResponder_with_dialogdata( in ScopedName responder, in TcUser initiator, in AssociationId initiator_a_id, out AssociationId responder_a_id, in string protocol_version, in DialogUserData d_u_d, in TcContextSetting tc_context_setting) raises(CosLifeCycle::NoFactory, NoMoreAssociations, InvalidParameter, UnsupportedTcContext); }; // end TcUserGenericFactory Creation of Implicit Associations --------------------------------- This case is more problematic since it is not possible to have the responder send the receiver its new association id during the implicit call without adding an out AssociationId on every call. This is undesirable to say the least. Instead the implicit association is signalled by the initiator through the use of the DialogFlowCtr flag being set to BEGIN, and the AssociationId::minor value OF THE RESPONDER being incremented by one. The responder then creates a new dialog with the initiator's AssociationId::minor value set to the same value as that passed in by the initiator. If the minor value exceeds the allowed number of dialogs (or minor dialogs) for the TcUser, the NoMoreDialogs exception is raised instead. This doesn't require any changes to the IDL. This solution solves the need for unique association ids and allows for the pre-allocation (and block allocation) of memory for association ids, helping to increase predictability and throughput of the gateway. For example, the full number of allowed associations (with a minor value of 0) can be allocated during the construction of the TcUser. Additional implicit associations can be added in block allocations when necessary. If, for example 20000 associations maximum can be handled simultaneously, and none use the implicit method of creation, then only 2000 x sizeof(CORBA::long)*2 bytes needs to preallocated. If the implicit method is used, then blocks of say associationids can be created when needed. This is preferable to the need to allocate possibly 200 bytes or more per dialog dynamically. Regards Neill Jones Teltec, DCU