Re: Binding to no particular address/INADDR_ANY?

Frank Rehberger wrote:
>  On 16.09.2010 13:54, Toralf Lund wrote:
>   
>> When setting up a TCP/IP based server ORB, I can specify the IP
>> host-name to bind to *via option -ORBIIOPIPName=..., or use an
>> internal default, which is influenced by the value of -ORBNetId. But
>> it does not seem like I can choose not to bind to an address at all,
>> as in set up the server to listen for connections on ANY interface the
>> machine may have. Why is that? Or is there some way I can do this?
>> I've **-ORBIIOPIPName=0.0.0.0 based on the theory that this would be
>> like specifying INADDR_ANY in a socket address structure, but it
>> didn't seem to work...
>>     
>
> ORBit2 has not been designed for this case. Nonetheless, it would be
> possible to add this INADDR_ANY  feature.
>
> Listening to all interfaces, would require to encode all endpoints into
> each object reference, which could be implemented quite easily, but
> blowing up the IORs extremely. Moreover, using this strategy for
> clients  it becomes unclear which of the encoded endpointsin IOR is
> reachable/routable, which may cause timely connection-trials.
>   
I don't understand what you are talking about here, I'm afraid. Doesn't 
the object reference just need one (any usable) address? Isn't 
everything ultimately about mapping the CORBA stuff into a socket (and 
vice versa), which just works for INADDR_ANY?
> If you need an ORB being able to listen to all NICs attached, I
> recommend The C++ ACE ORB (TAO). TAO is listening to all NICs by default.
>   
Quite. I've thought about switching many times. However, I rather like 
the way ORBit2 transparently integrates into my Glib/Gtk or Qt (via its 
Glib support) applications, i.e. that I can just run the normal mainloop 
and have all the CORBA calls appear without having to think about them. 
With other ORBs I generally have to use extra threads or cumbersome 
timer-based polling, right?
> Beside this, by default ORBit2 is using  Unix-Domain-Sockets, so the
> ORBIIOPIPName option will not have taken effect at all, I assume. To get
> ORBit2 servers  talking with remote hosts, the following command line
> parameters should be set:
>   
I knew that, of course...
> -ORBLocalOnly=0  -ORBIIOPUNIX=0 -ORBIIOPIPv4=1 -ORBIIOPIPName=A.B.C.D 
> -ORBIIOPIPSock=PortNum
>
> Adding the following option will change  to corbaloc IOR string format,
> which eases to figure out effect of command lines parameters.
> -ORBCorbaloc=1
>
> You can use the orbit-name-server-2 to verify:
> /usr/bin/orbit-name-server-2 -ORBCorbaloc=1 -ORBLocalOnly=0 
> -ORBIIOPUNIX=0 -ORBIIOPIPv4=1 -ORBIIOPIPName=A.B.C.D  -ORBIIOPIPSock=PortNum
>
>
> If you try -ORBIIOPIPName=0.0.0.0 and check the object-reference
> printed  to console, you will notice that ORBit2 encodes 0.0.0.0 into
> the stringified object reference, which is invalid and not reachable by
> any client.
>   
I suppose that's the problem... Although I don't use the stringified 
object references - frankly I think the whole concept of those is 
fundamentally flawed when it comes to setting up a proper networked app. 
So I'm relying on "static" corbaloc references. Supporting those is not 
really documented, and requires the use of a semi-private function, but 
actually it all works rather well.

- Toralf


This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.