dhcp questions

[stephan]

Hi there,

I have to support DHCP driven networks for an application I'm working on.

My first question on this is if anyone can give me some hints on this scenario to avoid running into too many pitfalls.

In particular, one "server" object has to keep track on each machine (the "clients", represented by Ice objects in this case) in the network, currently the machine is identified on it's IP address. However, this will not work any more with DHCP so I thought, creating UUID tokens for identification is the only solution.
These tokens would have to be stored locally on the clients and be submitted on re-registering to the server object.

Also, I suspect that storing proxy handles for the clients will not help in case that a particular client reconnects with a different IP address. To put it another way: I assume that an Ice proxy handle breaks on IP changes, right?

regs,

Stephan

[michi]

Whether a proxy breaks on change of IP address depends on your setup. If the proxy contains the IP address (instead of a domain name), it will break (obviously). If the proxy contains a domain name instead of an IP address, and if your DNS is up to date, there is no problem.

Machines that get their IP via DHCP can often be configured to update the local DNS with their new IP. Doing this would probably be the best way to keep everything working. Alternatively, you could come up with a session concept where clients contact the server with their details when they first come up. But, ideally, try to fix the problem at the DNS level. That will not only solve the problem for Ice, but for anything else that is IP-based.

Cheers,

Michi.

[marc]

You might also consider to use indirect proxies with IcePack. Then you only need to configure the IcePack locator, and all your proxies will only have symbolic addressing information (adapter id plus object identity). The real IP address is then resolved with IcePack. This happens transparently at runtime. For more information, please see the chapter about IcePack in the manual.

[stephan]

Thanks for your answer michi,

it answers quite a lot of my questions.

Originally posted by michi
Alternatively, you could come up with a session concept where clients contact the server with their details when they first come up. But, ideally, try to fix the problem at the DNS level. That will not only solve the problem for Ice, but for anything else that is IP-based.

If I don't know about the DNS/ DHCP setup at the place where the app is being installed, I assume that the session concept will be the only choice I can make, right?

regs,

Stephan

[bernard]

At least for the server, I think it's a reasonable requirement to have an up-to-date DNS entry!

For the clients, if you need to call them back, the safest is to register a callback at start-up with a unique (per-client) id. Assuming you use IP addresses and no DNS for the clients, this IP will remain valid as long as this client maintains the DHCP lease. In particular, if the client machine stays up and connected to the network (DHCP server), its IP address won't change, unless there is some administrative action like a reassignment of the IP-space offered by the DHCP server.

Now, if the client machine is shut down and restarted after the expiration of its DHCP lease, your client app can re-register its callback when it's restarted. Easy. A more interesting scenario is if your client application keeps running while the IP address changes: for example the machine was disconnected for a long time -- maybe it's a laptop "suspended" for a while. In this case, the application would need to detect this IP address change, restart its object adapter and re-register the callback ... typically in a background thread.

Cheers,
Bernard

[michi]

Finally, as Marc suggested, have a look at IcePack. With IcePack, you only need a single machine with a fixed domain name that resolves correctly to an IP, and all the other machines can have dynamically assigned IPs. IcePack then takes care of working out where a particular service is running, and clients transparently resolve the current address of a server they want to call.

Cheers,

Michi.