James Carlson wrote:
> Except for things that are entirely specified and controlled by local
> configuration data, there is no bound on when that state above might
> be reached.
>
> In other words, if you're using BOOTP, DHCP, or RARP to acquire
> interface addresses, you may have to wait "forever" for this event to
> occur. "Forever" is almost certainly too long for anyone's patience
> to hold out.
Correct. This means that those services which depend on
milestone/network will not be started in this "waiting
period." The standalone profile will be used in the mean
time.
> Similar things occur if we have to wait on indeterminate behaviors in
> the lower layers, such as 802.1X or 802.11 AP interactions. There's
> just no telling when or if those will ever converge, and that's not
> necessarily a bug.
>
> So, I would assert that either the time is ripe to open sockets when
> time begins (which is when the ip module itself is loaded and 'lo0'
> logically becomes available), or that there just is no such time that
> can be reliably determined for all systems.
I guess the question is not about whether a time can be
determined such that there is external IP connectivity, as
we can certainly determine such time. The question is
whether this time is useful or not. The argument is that the
network connectivity can come and go at any given time. So
what is the point of finding the very first time? And to
make things worse, the connectivity can be flaky such that
the system are bouncing between connected and not-connected
states. To make thing even worst, what outside IP connectivity
really means is not clear. For example, the machine may be
able to contact other hosts in the same sub network but not
outside that. Does it mean that it has "limited connectivity?"
In summary, it is not that useful to have such milestone.
> Otherwise, you're stuck in an unreliable world. You have to launch
> those configuration services, wait "a while" for them to start, then
> just throw your hands in the air and continue on as if they had
> actually started in the event that you get tired of waiting. That
> makes the milestone (and anything that depends on it) unreliable.
>
> Backing up to the original problem: what actually does depend on
> milestone/network _and_ also needs to have some non-lo0 interface
> plumbed? Are any of these dependencies not bugs?
No, I don't believe the intention of milestone/network is
about plumbing interface. It is about outside IP connectivity.
Have I summarized the argument against this milestone above
correctly? So the question is about what services depend on
outside IP connectivity before they should be started. I
suppose there are at least a couple, such as xntpd.
> If any of them are not actually bugs or design flaws in those
> services, then I'd like to understand how that's the case.
I don't think it is a bug for xntpd to depend on external IP
connectivity before it should be started.
> In order to talk with the outside world safely, IPsec and IP Filter
> both need to be initialized.
We've discussed this. I guess milestone/network needs to
depend on the above.
> Those are simple internal processes -- loading files and stuffing bits
> into the kernel -- that do not depend on any external behavior. Nor
> do these activities (as far as I understand) depend on plumbing or
> configuring any IP interfaces other than perhaps loopback.
Sure.
> That makes them rather different from configuring interfaces, unless
> "configuring" doesn't actually mean waiting for the interfaces to
> become usable.
I think the key problem with milestone/network is whether
or not it is useful because connectivity can come and go,
and the meaning of connectivity is not that clear. I suspect
that for most customers, connectivity really means that a
machine can contact hosts in the same sub network. If there
is a problem contacting hosts outside that, most customers will
consider that as a network problem, such as the router is
not functioning. And I believe NWAM can determine this simple
situation. For flaky connectivity, I again suspect that it
is not a common case such that NWAM can detect that and inform
the user.
I guess the basic question is whether external IP connectivity
is a useful state of the machine such that we need to make it
a milestone for other network services to depend on, both for
backward compatibility and for future usage. Comment?
--
K. Poon.
kacheong.poon at sun.com
