Issues for Unreliable Multicast FTF

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 6575: struct GroupInfo {
Issue 6576: Figure 29-1: Box "Number_of_profiles"
Issue 6577: within a object group domain
Issue 6578: repository id
Issue 6579: ObjectGroupId get_object_group_ref (in ObjectGroup object_group)...
Issue 6580: Return Value The identifier of the object group
Issue 6581: methods in interface PropertyManage
Issue 6582: excluded from the group IOR
Issue 6583: typedef CosNaming::Name; struct Property { Name nam; Value val; };
Issue 6584: PortableGroup::ObjectGroupManager {}
Issue 7687: Shouldn't the GOA >interface be a local interface?
Issue 8863: anonymous types
Issue 10799: Unreliable Multicast issue

Issue 6575: struct GroupInfo { (umcast-ftf)

Description
ORIGINAL: struct GroupInfo { 

CORRECT: struct TagGrouppedTagComponent {
 

ORIGINAL: Figure 29-1: Box "Number_of_profiles" 

CORRECT: Figure 29-1: Exclude the box "Number_of_profiles", because there is no such attribute in IDL.

ORIGINAL: within a object group domain 

CORRECT: within an object group domain OR within a default object group domain

ORIGINAL: The repository id for which the properties, that are to override the CORRECT: The repository id OF THE OBJECT GROUP for which the properties, that are to override the

ORIGINAL: ObjectGroupId get_object_group_ref (in ObjectGroup object_group)... 

CORRECT: ObjectGroup get_object_group_ref (in ObjectGroupId object_group)...

ORIGINAL: Return Value The identifier of the object group 

CORRECT: Return Value The current reference of the object group

Why methods in interface PropertyManager throw ObjectGroupNotFound but methods in GenericFactory interface throw ObjectNotFound ?

ORIGINAL: exluded in the group IOR 

CORRECT: excluded from the group IOR

ORIGINAL: typedef CosNaming::Name; struct Property { Name nam; Value val; }; SUGGESTION: typedef string Name; struct Property { Name nam; Value val; }; REASONS: string is more suitable to handle

ORIGINAL: PortableGroup::ObjectGroupManager {} 

CORRECT: PortableGroup::ObjectGroupManager {};

A question about the MIOP spec (ptc/03-01-11). Shouldn't the GOA >interface be a local interface?

This draft spec uses anonymous types which are deprecated in the core corba spec (see 3.11.6 of 04-03-12

I have a few questions after reviewing the MIOP specification.

 

The MIOP specification addresses issues that occur when using an unreliable transport, in particular UDP. The MIOP header that wraps GIOP request fragments is useful for packet reassembly. What I don’t understand is why this technique is limited to multicast addressing, when it would be equally useful with unicast addressing when using UDP, subject to the same constraints (GIOP requests with no response expected -- oneway operations only).

 

There are circumstances when <<signals>> (oneway requests) directed to a specific endpoint (interface realization) may be desirable instead of to a group; when in fact the designer wishes to preclude multicast. Section 29.14 limits the address range to Class D IP addresses, is it possible to permit unicast addresses in the spec.

 

It appears to me that the problem should be handled in 2 steps:

 

First, handle the issues regarding GIOP over unreliable transports

Limit transmissions to GIOP request messages with no replies

Provide mechanism to handle fragments

 

The preceding issue is done with the extra encapsulation (MIOP header)

 

Second, handle the issues regarding network addressing

unicast

multicast

 

There is a difference between the transport and network layers in the ISO/OSI communication model for a reason. Maintaining this distinction allows a more robust use of the transport by permitting its use with more than one network addressing mode.