[omniORB] Curious omniNames Behavior

[Ken Feuerman]

Bjorn,

Thanks again!  Yes, DHCP is dynamic allocation and assignment of IP
addresses.  Would you say that the resolver you mention is essentially a
NameService?

Something I didn't make clear in my original scenario is that there is no
reboot of the machine between the initial startup of omniNames and the
restart of omniNames.  Therefore, the IP address assigned to the machine
could not have changed in between.

I'm trying the suggestion by Steven Brenneis about making sure the registry
entry is recorded in order for omniNames to work properly.  (Unfortunately
I'm only in email contact with the site that's experiencing the problem, so
the turn-around time is pretty lengthy.)  I'll try to keep you all posted.

--Ken Feuerman.

At 11:47 AM 7/15/99 +0200, you wrote:
>Ken Feuerman <kfeuerma@Adobe.COM> writes:
>
>> Thanks Bjorn & Steven for your replies.
>> 
>> Both of you mentioned the Win32 Registry entry for recording the IOR
>> generated in the start call to omniNames.  True that I haven't been
>> recording that entry into the registry, because I'm working with another
>> ORB that also must get a hold of the NameService root context (I record the
>> root context IOR into a "well-known" file, and all processes in my system
>> know to look there regardless of which ORB they're using).
>> 
>> But what's curious is that this problem of generating a localhost-based IOR
>> has never come up before on machines with fixed IP addresses, only on
>> DHCP-based machines.  In other words, on hosts with fixed IP addresses, I
>> can omit the registry entry for the NameService, yet still always generate
>> a correct (non-127.0.0.1) IOR.
>> 
>> The real question I have is:  Suppose I have the situation where omniNames
>> is restarted on Machine A displaying this localhost-based IOR.  Suppose
>> further that I have a hold of the original IOR with the correct IP address
>> encoded from the time when the omniNames was originally started.  Should I
>> expect this behavior where processes on Machine A can indeed contact the
>> NameService using the original IOR, but processes on some remote Machine B
>> can't (using the same original IOR)?
>> 
>> Thanks for your advice/help!
>> 
>> --Ken Feuerman.
>
>(I'm assuming that DHCP is dynamic ip-addressing)
>I added a option to BOA called -BOAiiop_name_port (included in
omniORB-2.8.0).
>The motivation was that I often found myself starting servers at my 
>home computer that changed ip-numbers each time I logged on the network.
>
>Starting my servers with './server -BOAiiop_name_port
online30001.provider.net:12000'
>forces the ip-address 'online3001.provider.net' into the IOR. On the 'far'
side,
>I could then resolve and connect to this hostname:port.
>
>I do think that omniNames can be started with this option.
>
>To answer your question: no. The original IOR is not valid anymore since
you now
>have omniNames running on a machine with different IP-address. If I were you,
>I would write a deamon that acts as a resolver. Whenever you start a server
>you register with your resolver and publish your IOR. Other servers/clients
>that wishes to use your services first contact your resolver and ask for
>a service - and the resolver provides the IOR to the current running service.
>
>This is actually not a big job to do when you are dealing with corba. We did
>exactly this last year and since that we have not been using omniNames :-)
>
>bjornw>
>
>