On 25 Jan 1999, Love wrote:

> "Peter J. Braam" <braam_at_cs.cmu.edu> writes:
> 
> > On Sun, 24 Jan 1999, SOM Bandyopadhyay wrote:
> > >             a) how do u handle DHCP address change?
> > 
> > Probably this works just fine.  I don't think that the IP of the client is
> > every stored across disconnection, as you see above.  When that client
> > comes back, with a different IP, the server just sees a new client, but
> > that is fine.  Admittedly, this may not quite work correctly at the
> > moment, but the what I am trying to say is that I don't see a design
> > problem.
> 
> New client -> the client will not receive the break-ing of callbacks
> from the server (that will be sent to the old address). 

The point is that a new client wouldn't have any callbacks and the server
doesn't know about it, so there is nothing to break.  New clients
VALIDATE, callbacks are ONLY used during connectivity.

[The only problems that could happen at present is the following.  If the
client has two interfaces with different IP's and is using both to talk to
the same server, then almost certainly our code has flaws and will confuse
the callbacks.]

> 
> If the client is smart enough to see that the adress has change you'll have
> a performance loss (I don't think that the client, rpc2_LocalHost is
> exported from rpc2 but I can't see any use for it).
> 

We are taking the IP addresses out of the UDP header [except for MGrp
hashing which we are about to change, but that doesn't affect this
discussion].  The whole rpc2_LocalHost function variable will not be
needed anymore.

- Peter -

> I don't think that its a real problem.
> 
> Love
> 
> 
> PS I don't know how useful that afsUUID would be (since the only
> documention we have is headerfiles and tcpdump :( ) But if the client could
> re-register like the server, it could problably work. DS
>