[Ace-users] NamingService behind proxy not working as expected

[Manuel Castro]

Thanks Johnny! I added hostname_in_ior  to my server process and now
it works.

Now another problem appeared that we couldn't solve either, that could
be titled "NotificationService behind proxy not working as expected",
but I will keep it in this thread to be related with previous
question.

The client applications now connects to the server, obtains proxies
objects and make method invocations properly.
A new problem appears when connecting to the NotificationService.

All invocations go ok at client side:
new_for_consumers invocation, gets default_filter_factory,
create_filter, add_constraints, subscription_change and
obtain_notification_push_supplier.

Then, the client invokes "connect_structured_push_consumer", and
inside the sniffed frame is contained the following:

GIOP............
...........#....
NUT...G.O.......
................
...!connect_stru
ctured_push_cons
umer............
...5IDL:omg.org/
CosNotifyComm/St
ructuredPushCons
umer:1.0........
.......H........
192.168.1.3..,..
....4895108889/.
.(.%+..F at .......
............JAC.

where appears the cliente local IP address (192.168.1.3), so the
NotificationService tries to connect that IP (this is with -
ORBDebugLevel 10), instead of detected external IP.

TAO (5556|2332) - IIOP_Connector::make_connection, to
<192.168.1.3:2604> which should block
TAO (5556|2332) - Transport_Connector::wait_for_connection_completion,
going to wait for connection completion on transport[21041228]
TAO (5556|2332) - Leader_Follower[21041228]::wait_for_event, (leader)
enter reactor event loop


I looked up the entire Chapter 27 in the "TAO Developers guide" for
any solution and also looked up this forum, but couldn't find any
info.

I don't know if it should be set something at NotificationService side
or at client side.

Any help will be welcome.
Thanks in advance again.
Manuel Castro









On Feb 12, 1:17 pm, "Johnny Willemsen" <jwillem... at remedy.nl> wrote:
> hi,
>
> Try to add hostname_in_ior also for your real server.
>
> Regards,
>
> Johnny Willemsen
> Remedy IT
> Postbus 101
> 2650 AC  Berkel en Rodenrijs
> The Netherlandswww.theaceorb.nl/www.remedy.nl
>
> *** Integrated compile and test statistics seehttp://scoreboard.theaceorb.nl***
> *** Commercial service and support for ACE/TAO/CIAO             ***
> *** Seehttp://www.theaceorb.nl/en/support.html                ***
>
> "ManuelCastro" <castro.man... at gmail.com> wrote in message
>
> <news:2680a8e8-7a5a-4d26-9369-c98988a28fa0 at 1g2000hsl.googlegroups.com>...
>
> > Hi,
> >  we've got a problem with a NamingService accessed from an external
> > client. I'm sure it's not a TAO bug, but a misconfiguration of ours.
> > We bought the "TAO Developer's Guide 1.4a", but we couldn't find the
> > solution.
> > Any help will be welcome.
> > Thanks in advance.
> >ManuelCastro
>
> >    TAO VERSION: 1.5
> >     ACE VERSION: 5.5
>
> >     HOST MACHINE and OPERATING SYSTEM: Windows2003 Server SP2
>
> >     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
> > WindowsXP Prof.2002 SP2
> >     COMPILER NAME AND VERSION (AND PATCHLEVEL): VC++2005 8.0.50727.762
> > (SP.050727-7600)
>
> >     THE $ACE_ROOT/ace/config.h FILE
> >     #include "ace/config-win32.h"
> >     #define ACE_HAS_VERSIONED_NAMESPACE 0
> >     #define ACE_HAS_STANDARD_CPP_LIBRARY 1
> >     #define ACE_MUST_HELP_DLOPEN_SEARCH_PATH 1
>
> >     AREA/CLASS/EXAMPLE AFFECTED: NamingService
>
> >     DOES THE PROBLEM AFFECT:
> >         COMPILATION? No
> >         LINKING? No
> >         EXECUTION? Yes, TAO
> >         OTHER (please specify)?
>
> >     SYNOPSIS:
> >     Host name supplied in IORs is not always the expected one
>
> >     DESCRIPTION:
> >     A CORBA client application connects from outside of our network.
> >     NamingService is running as a service, at machine 1.2.3.4 with the
> > following registry entry for "TaoNamingServiceOptions" key:
> >     -m 0 -ORBListenEndpoints
>
> iiop://external.domain.es:15000/portspan=299&hostname_in_ior=external.domain
> .es
>
> >     All traffic to external.domain.es is redirected to machine
> > 1.2.3.4.
> >     Wireshark is sniffing at 1.2.3.4 host.
> >     When client application connects, and sniffing GIOP protocolo, we
> > get a first response:
> >     IOR::type_id: IDL:omg.org/CosNaming/NamingContextExt:1.0
> >     IIOP::Profile_host: external.domain.es
> >     IIOP::Profile_port: 15000
> >     This is ok.
> >     Then client application asks for MinDevControl_Factory proxy, but
> > the response includes the following:
> >     IOR::type_id: IDL:MinVClient/MinDevControl_Factory:1.0
> >     IIOP::Profile_host: 1.2.3.4
> >     IIOP::Profile_port: 15600
>
> >     So the client can't connect to 1.2.3.4 since it's an internal IP.
> >     We thing the response should include something like:
> >     IOR::type_id: IDL:MinVClient/MinDevControl_Factory:1.0
> >     IIOP::Profile_host: external.domain.es
> >     IIOP::Profile_port: 15600
>
> >     REPEAT BY:
>
> >     SAMPLE FIX/WORKAROUND:
> >       No workaround so far.