Re: Pre-down script?



On Fri, 2006-02-17 at 09:52 +0100, Tim Niemueller wrote:
> Dan Williams wrote:
> > On Thu, 2006-02-16 at 22:06 +0100, Christian G�rote:
> > 
> > Not really.  How exactly are you supposed to know that the connection is
> > "down" before it _is_ actually down?  The only case where you can know
> 
> We can now in the case of receiving a sleep signal via dbus. If we shut
> down a VPN there also some kind of link going down. For instance at
> university you have touse VPN or you can only connect to an
> informational web server.
> 
> What would help is a general awareness of the system about connections.
> For example Gaim could use that to logout properly from the IM networks
> you are connected to, some kind of dyndns service could set a special IP
> address that makes you know that the machine is down.

Yes, thinking about this more last night I convinced myself that it
would be helpful to expose two classes of disconnect, sort of like
"forced disconnect" (ie, network drops, cable pulled) and "graceful
disconnect" (ie, user chooses to switch).

However, I don't think that's really possible to get right.  The problem
here is switching speed.  If the user chooses to switch connections, how
long do we wait for "pre-down" operations to complete?  2 seconds?  3
seconds?  The user wants to switch quickly, and adding more delay to
that process isn't the solution.

And I did realize that we do "pre-down" for VPN connections.  The only
reason that works is because it's really quick and its inside the NM
stack.  So at the risk of being a hypocrite, I'm not sure we should
expose that outside NM.

If we did, how do we do it?  We could execute pre-down actions in
parallel, and 1s or 2s later, kill the connection.  We then live with
the increased latency of connection switching, which will only affect
those with pre-down actions anyway.  But it's not good to set a
precedent of lagging NM with any arbitrary number of possible pre-down
actions.  There will also inevitably be people who want "just one more
second."  I'm not sure this is such a good idea...

Dan





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]