Re: [tao-users] Corba server behind firewall/nat and clients using IIOP works with a minor problem - PRF
Phil Mesnier
> Hi to everyone,
>
> Following Phil's suggestion this is the PRF:
>
> TAO VERSION: 2.0.1
> ACE VERSION: 6.0.1
Thanks for the PRF. I see you've updated to the latest TAO.
> --------------------------------------------------------------------------------------------------------------------------------------------------------
> REPEAT BY: Trying to use ORBUseSharedProfile 1 with multiple
> -ORBListenEndPoints on tao_imr_locator and on servers registered on IMR
> produces a single profile with a single endpoint (CASE 1). If I use
> -ORBUseSharedProfile 0 (default) on tao_imr_locator it produces several
> profiles (one per endpoint specified through -ORBListenEndPoints) with
> one endpoint (CASE 2).
> Let me clarify with some message debugging.
I think the problem may be with the corbaloc strings. A corbaloc
reference is really just a "hint" on how to find the real reference. As
a hint, there are typically no tagged components. When provided a
corbaloc reference, the client ORB must synthesize an IOR it can use to
actually connect. That means you also need to pass -ORBUseSharedProfile
1 to the client ORB as well.
I tried an experiment and found that when I passed multiple endpoints to
a corbaloc string without the sharedprofile, it synthesized an IOR with
multiple profiles. When I enabled sharedprofile, I got a single profile,
but with a single endpoint, no alternate endpoints in a tagged component
as expected.
I think you've got a couple of choices. You can extend the corbaloc
parser to synthesize profiles with multiple endpoints, or you can modify
your deployment strategy so that the clients using corbaloc only use a
single endpoint at a time - perhaps a simple configuration option that
selects internal/external network use, and if internal it could decide
whether 192.168.2.128 or 192.168.106.1 is more appropriate and generate
its own corbaloc string.
BR,
Phil
--
Phil Mesnier
Principal Software Engineer and Partner, http://www.ociweb.com
Object Computing, Inc. +01.314.579.0066 x225
Ariel Brunetto
Thank you for the reply. I am using the reference sent to me by the Implementation Repository as you could see in my previous email. Anyway, I do understand the corbaloc url style and tagged component issue, but I think that it is not my current problem, because I am using the reference sent by the tao_imr_locator, and the tao_imr_locator only sent to me a single profile with a single endpoint. If I do the same with other object instead of the tao_imr_locator (for example directly to the DataManager object bypassing tao_imr_locator) I get a single profile with multiple endpoints.
My question is why the tao_imr_locator sent to me a single profile with a single endpoint instead of send me a single profile with multiple endpoints as do my server objects?
Regards,
Ariel
________________
Ariel Brunetto
www.aquadize.com
Ariel Brunetto
Is it possible that GIOP LOCATION FORWARD messages doesn't support tagged components such as multiple endpoints?
Regards,
Ariel
Ariel Brunetto
I have more info. The method create_profile_body() (see below) is called previous to send the LOCATION FORWARD message to create some parts of the output message string. As you can see it only takes care of one endpoint.
I found a method for doing what I want:
/// Encode alternate endpoints for non-RT profiles, using multiple
/// TAG_ALTERNATE_IIOP_ADDRESS components, one endpoint per component
virtual int encode_alternate_endpoints (void);
But this method is not call in any place inside TAO. What am I missing?
Regards,
Ariel
TAO_IIOP_Profile::create_profile_body (TAO_OutputCDR &encap) const
{
encap.write_octet (TAO_ENCAP_BYTE_ORDER);
// The GIOP version
encap.write_octet (this->version_.major);
encap.write_octet (this->version_.minor);
// STRING hostname from profile
#if defined (ACE_HAS_IPV6)
// For IPv6 decimal addresses make sure the possibly included scopeid
// is not published as this has only local meaning.
const char* host = 0;
const char* pos = 0;
if (this->endpoint_.is_ipv6_decimal_ &&
(pos = ACE_OS::strchr (host = this->endpoint_.host (), '%')) != 0)
{
ACE_CString tmp;
size_t len = pos - host;
tmp.set (this->endpoint_.host (), len, 1);
encap.write_string (tmp.c_str ());
}
else
#endif /* ACE_HAS_IPV6 */
encap.write_string (this->endpoint_.host ());
// UNSIGNED SHORT port number
encap.write_ushort (this->endpoint_.port ());
// OCTET SEQUENCE for object key
if (this->ref_object_key_)
encap << this->ref_object_key_->object_key ();
else
{
ACE_ERROR ((LM_ERROR,
"(%P|%t) TAO - IIOP_Profile::create_profile_body "
"no object key marshalled\n"));
}
if (this->version_.major > 1 || this->version_.minor > 0)
this->tagged_components ().encode (encap);
Ariel Brunetto
I would like to correct last email. The method encode_alternate_endpoints() is called in one place: TAO_Default_Acceptor_Filter::encode_endpoints (TAO_MProfile &mprofile).
Regards,
Ariel
Phil Mesnier
> Hi!
>
> I have more info. The method create_profile_body() (see below) is called
> previous to send the LOCATION FORWARD message to create some parts of
> the output message string. As you can see it only takes care of one
> endpoint.
>
> I found a method for doing what I want:
>
> /// Encode alternate endpoints for non-RT profiles, using multiple
> /// TAG_ALTERNATE_IIOP_ADDRESS components, one endpoint per component
> virtual int encode_alternate_endpoints (void);
>
> But this method is not call in any place inside TAO. What am I missing?
>
It is actually called from within the PortableServer library to generate
the tagged component. See TAO_Default_Acceptor_Filter::encode_endpoints ().
Once added to the set of tagged components, it should be carried with
the profile just like any of the others. At that point the components
are handled generically. When looking at the forwarded IOR, did you see
any components? There should also be one for ORB ID and one for
codesets. If these are not attached, then there is a fundamental issue
with the propagation of tagged components in general. If there are other
components present, but not TAG_ALTERNATE_IIOP_ENDPOINTS then we need to
dig further to find out why.
The final IOR forwarded ought to be the real IOR provided by the server
to the IMR once the server is active and ready to accept requests.
Do you have the emails you and I exchanged in Sept / Oct of 09? We
discussed a problem similar to this then, and decided that you needed to
use -ORBUseSharedProfile 0 apparently because of this problem. I haven't
read those old messages in detail, but I think I caught the idea that
the ImR synthesizes an IOR and apparently doesn't do the alternate
endpoints.
So it sounds like there may be some code rewrite necessary to accomplish
what you are looking for.
A couple of years ago you said you were considering a support contract
with OCI. I would like you to do that now, because I think you are
looking at something like 8-24 hours of effort to provide a fix, verify
the fix and get it committed to the repository.
If you don't want to fund the effort of solving this, then I suggest you
write up a bugzilla entry, including a sample program that demonstrates
the flaw, and perhaps a proposed solution.
Best regards,
Ariel Brunetto
I am trying to solve this problem using Portable Interceptors, but I couldn't. As far as I know the PI are called after the resolve() method in the Profile Transport Resolver, and my problem is in that method, because when it tries to reach an unreachable endpoints in the first profile it waits until timeout, which is what I want to avoid. Is there any other way to intercept this request?
I just want to skip the first profile and tries the second one, before any connection attempt to the object. I want to intercept the very first connection attempt to the object and skip the first profile. Is it possible?
Thanks in advance!
Ariel