Bug 1945

Summary:	Using multicast discovery for both IFR and Naming service fails
Product:	TAO	Reporter:	Markus Stenberg <markus.stenberg>
Component:	ORB	Assignee:	DOC Center Support List (internal) <tao-support>
Status:	NEW ---
Severity:	major
Priority:	P3
Version:	1.6.5
Hardware:	x86
OS:	Linux
Attachments:	Sample code which exhibits the problem

Description Markus Stenberg 2004-09-23 05:31:25 CDT

I'm not sure if they're meant to work together or not, but it's quite annoying
that they seem to be unable work together when using multicast discovery.
Judging by very, very brief debugging I did the return value for the
ResolveInitialReferences is ALWAYS that of the first looked for (NamingService,
InterfaceRepository), and therefore things fail miserably.

Is this bug or feature? I could see some justification in calling it a feature,
but if so, it's still annoying one.. especially as default IFR implementation
doesn't register itself to NS so I need to look it up currently using the .ior
file it generates.

Comment 1 Markus Stenberg 2004-12-29 07:38:09 CST

I also wrote test code to check this if someone cares. Example output of the
symptom:

NS IOR is:
IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e300000010000000000000094000000010102002200000069703231322d3232362d3135362d36312e6164736c2e6b706e71776573742e6669007ce43300000014010f004e5550000000150000000001000000004e616d65536572766963650000000000010000004e616d65536572766963650002000000000000000800000001000000004f415401000000140000000166914001000100000000000901010000000000
IFR IOR is:
IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e300000010000000000000094000000010102002200000069703231322d3232362d3135362d36312e6164736c2e6b706e71776573742e6669007ce43300000014010f004e5550000000150000000001000000004e616d65536572766963650000000000010000004e616d65536572766963650002000000000000000800000001000000004f415401000000140000000166914001000100000000000901010000000000
assertion failed at 67

I'll see if I can track it down tomorrow, but according to strace the multicast
port used is always the first one used, and therefore (in this case) IFR is
requested for within the NS multicast port, and the remote side doesn't care
what was asked for and always returns NS IOR.

Comment 2 Markus Stenberg 2005-01-10 06:39:45 CST

Applies also for 1.4.3.

Comment 3 Johnny Willemsen 2005-01-10 06:53:00 CST

Could you attach your test program to this report. People are very busy so we 
can't make a guarantee when we will have a look. If you have proposed patches, 
add them to the report as well.

Comment 4 Markus Stenberg 2005-01-10 07:02:51 CST

Created attachment 297 [details]
Sample code which exhibits the problem

Comment 5 Markus Stenberg 2005-02-18 08:13:55 CST

This is also in 5.4.4.

The problem code was also found, it's logic being roughly, 'first multicast
exact port we get, we use it for rest of traffic', which is downright wrong, as
the NameService and IFRService multicast discovery are on different ports.

This kludge enabled the test code I provided to work correctly (by overriding
the mcast:// prefixes whenever we lookup for a service, I'm not sure if this is
correct behavior BUT it works for us):

diff -u {ace-5.4.4,ACE_wrappers}/TAO/tao/ORB.cpp
--- ace-5.4.4/TAO/tao/ORB.cpp   2005-01-21 18:43:44.000000000 +0200
+++ ACE_wrappers/TAO/tao/ORB.cpp        2005-02-18 15:46:54.000000000 +0200
@@ -1079,7 +1079,7 @@
   CORBA::String_var default_init_ref =
         this->orb_core_->orb_params ()->default_init_ref ();

-  static const char mcast_prefix[] = "mcast://:::";
+  static const char mcast_prefix[] = "mcast://:";

   if ((ACE_OS::strncmp (default_init_ref.in (),
                        mcast_prefix,

Comment 6 Johnny Willemsen 2008-08-06 08:26:53 CDT

still valid. string shouldn't be stored into default_init_ref but we should should store the string just for this service request and use that later in the orb core