Conference tuxedo::dce-products

2238.0. "Unexpected Binding Resolution with Non-nil Object UUID" by RTP4ME::GALLAGHER (Life is good!) Wed Apr 30 1997 19:02

    I have a question for all you DCE experts out there.  This is
    verbadum from a customer mail to me.
    They're config is:
    Production cell running DCE V1.3B w/ recent VAXLIB06_070 MUP
    VMS nodes running OpenVMS V6.1-1H3
    Client PC's running Windows 95
    
    
    Subject:  Unexpected Binding Resolution with Non-nil Object UUID
    
    I am in the process of converting a server application from an
    "export by interface" to an "export by resource" strategy.  While
    testing, I had two instances of the server running on the same host.
    Both registered the same interface-id to the endpoint map.  One
    specified a nil object UUID and the other specified a non-nil object
    UUID.  The endpoint map appeared as follows:
    
    $ rpccp show mapping -i 3a916c8a-a29f-11cf-8d1a-08002b1e7401,2.0
    
    mappings:
    
      <object>         nil
      <interface id>   3a916c8a-a29f-11cf-8d1a-08002b1e7401,2.0
      <string binding> ncacn_ip_tcp:<ip addr>[1861]
      <annotation>     /.:/opcenter/bocrds_wldev2
    
      <object>         5dcee6bc-bc11-11d0-88f1-08002b9d6c09
      <interface id>   3a916c8a-a29f-11cf-8d1a-08002b1e7401,2.0
      <string binding> ncacn_ip_tcp:<ip addr>[1594]
      <annotation>     /.:/opcenter/docrds_wldev2
    
    When my client calls rpc_ep_resolve_binding() to resolve a
    partially-bound binding handle with the object UUID set to the
    non-nil value (5dcee...), it gets bound to the server with the nil
    object UUID (i.e., endpoint 1861).  In other words, the nil UUID
    appears to be an acceptable match for a client specifying a non-nil
    UUID.
    
    This problem will eventually go away when all server instances use
    non-nil object UUIDs in the endpoint map.  In the meantime, I am
    running
    servers on different hosts to get around the problem, but would prefer
    to have them coexist until all of the clients are upgraded.  Is there
    a way to force a mismatch between the nil and non-nil object UUIDs?
    

Does anyone have any input on this one yet?

Thanks,
Ed

If the customer is not using the name service but directly composing the binding handle, the nil object UUID
should not match if the non-nil object specified.  You should enter a severity level 3 case on this problem. 
Include reproducer server/client code to expedite working the issue.  

If the customer is using name services, there could be a problem in what is exported to the name service and
what is registered in the endpoint map. Could you have the customer specify how the client is importing
information from the name service to determine what servers are available to manage the resource.  Are they using
the rpc_ns_binding_import_* or rpc_ns_binding_lookup_* routines to obtain the servers before resolving the binding
handle? 

dave

Dave,

	Thanks for the input.  I've varified with the customer that his 
problem could infact be a bug, so I've logged a call in it.  We can
reproduce the results at will and have the code to pass along.

Thanks again for your help,
Ed Gallagher