[tao-bugs] [TAO] Changing interface status after startup cause incomplete IOR
Benjamin.Schuele at karlstorz.com
Mon Aug 31 04:48:02 CDT 2015
Thanks for the quick answer!
I tried your 2.2ap7 and the 6.3.0 version, but with no success. In my opinion the IORTable does not help here.
The problem is not to have initial connection problems. The problem (bug in my opinion) exist if we have a mixed server/client architecture at least on one side. Like the TAO\examples\Simple\chat project, where the "chat client" acct as client to send messages to the server, and acct as server to receive the messages. The client register his server on the "chat server" with the
" server_->add (this->receiver_var_.in ()," line (in ACE_wrappers\TAO\examples\Simple\chat\Client_i.cpp). For this call, the IOR needs also to be generated. And this generation failed in the described case.
I'm also willing to spend some time fixing it, if you tell me where in the code I need to work.
Mit freundlichen Grüssen
Software Engineer Embedded Software EMDD
Tel.: +41 (0) 52 640 32 81
Fax: +41 (0) 52 640 30 23
benjamin.schuele at karlstorz.com
Von: Phil Mesnier [mailto:mesnierp at ociweb.com]
Gesendet: Freitag, 28. August 2015 14:39
An: Schuele, Benjamin
Cc: tao-bugs at list.isis.vanderbilt.edu
Betreff: Re: [tao-bugs] [TAO] Changing interface status after startup cause incomplete IOR
> On Aug 28, 2015, at 3:21 AM, Schuele, Benjamin <Benjamin.Schuele at karlstorz.com> wrote:
> TAO VERSION: 2.2.0
> ACE VERSION: 6.2.0
Thank you for using a PRF. Note that your version of TAO is no longer supported. For long term support I suggest you adopt OCI TAO 2.2a which is forked from TAO 2.2.0.
> HOST MACHINE and OPERATING SYSTEM:
> Ubuntu 14.04.3 LTS
> THE $ACE_ROOT/ace/config.h FILE
> #include "ace/config-linux.h"
> COMPILER NAME AND VERSION (AND PATCHLEVEL):
> gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
> THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE
just curious, what is your cross compile target?
> If a computer running a corba program get an IP (over DHCP) after object generation, the IOR send to other computers misses the new IP.
> We have a simple network device and a PC program talking each other with corba. In order to work without name resolution, we use the "-ORBDottedDecimalAddresses 1" option. If the user power up the device and connecting the network cable after the software is started, all GIOP call from the device sending an IOR to the computer misses the new IP. This cause the computer program to not be able to use this object pointer.
The best solution is DNS if that is at all possible. What happens if you don't use -ORBDottedDecimalAddresses 1 what happens?
There are a couple issues at hand here. First, TAO servers using defaulted listen addresses will enumerate the interfaces known at initialization time so those are the only ones included in the IOR. Second, when you advertise a fully qualified IOR in a file, there is no way for the server to update any consumers of that file even if the first issue is addressed.
Coincidentally OCI is getting ready to release a new patch for OCI TAO 2.2a which takes the first step towards addressing this situation. For it to work, the server must use the IOR table and clients must use "corbaloc:iiop:1.2@<host>:<port>/<iortablekey>" as its IOR. The IORTable in the server has a new "refresh" feature which causes it to update a bound IOR's list of endpoint addresses each time an IOR is requested. That should be available this afternoon US time.
Principal Software Engineer and Partner, http://www.ociweb.com
Object Computing, Inc. +01.314.579.0066 x225
More information about the tao-bugs