Subject: Re: DHCP client, integration with ifconfig, etc.
To: Dennis Ferguson <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 02/09/1997 17:21:11
>(2) Make sending broadcasts to 255.255.255.255 work so that things
> which want to broadcast don't have to dig through the interface
> address configuration to do it in the normal case (support for the
> non-interface-specific broadcast address comes for almost for free as
> a side effect of proper wire multicast support in any case).
I don't intuit quite how this is supposed to work on a multi-homed
host. To which interface(s) should the all-ones broadcast be sent?
>(3) Redo the routing socket so that it can be openned by a normal
> process, which can then request that notifications be sent whenever
> the interface address configuration and/or the local address set
> changes without receiving a bunch of other cruft as well. Asynchronous
> notification means that processes can find out about changes without
> having to periodically poll for an event which is unlikely to happen
> anyway. Some effort must also be spent making the routing socket
> reliable, or at least to provide a mechanism to cheaply detect when
> messages are lost.
That's one way; a signal is another. Signals can be an `nicer' hook
than to add to existing applications than polling. But there aren't
any more signals available, unless we grow expand sigmask.
But asynchronous I/O on a readonly routing socket (with a signal
indicating an interface change is available) could do almost as well.
>(4) Return errors to connected sockets when the address configuration
> changes in a way which leaves the sockets orphaned.
Yup. Though for an app blocked on a read that isn't going to complete,
a signal would be more useful. Or is that a case where you'd return
an error? Just in passing, there are more cases than `address
expired' that want errors. In a mobile world, having an interface
physically removed from the machine could, perhaps, be treated the
same way as an expired address.
I suspect that mobility is an area where it's possible to have
different models of what `proper' functionality, as seen by users, is;
and those different models can lead to different decisions about what
the correct technical (kernel-level) decisions are. The functionality
I tend to assume is one where a mobile user often has a choice of
available media, with different latency, bandwidth, and price
trade-offs, with some attempt to use these `intelligently'.
(That said, more flexibility is usually good.)