[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Are we connected ? - round II.
From:       Holger Thon <devel_ht () unidui ! uni-duisburg ! de>
Date:       1999-05-15 9:09:04
[Download RAW message or body]

Andreas Pour wrote: 

       Matt Koss wrote: 
         

       this.  But if the gateway does not understand the query, the only
thing to do is to
       try 
       to ping the outside world, I think . . .

Well, i don't think pinging is a good idea, for it produces dns-lookups
which - in my opinion - have to be avoided on DOD systems.  When the
target system uses a masqdialer Server, we already have the answer if
the gateway is connected or not.  When not, i think the administrator
should have alternatives of what to do with the gateway. On the
clientside, there could come a question like "You requested bar from
server foo. Perhaps you are not connected. Starting a connection might
produce costs billed by your provider. Shall i proceed now?". 

Maybe we can divide the connection options into something like this: 
1.) 08/15 (route on dev xy up means connection), includes dod/dial-up
over workstation 
2.) client over gateway 
   - assume permanent connection (-> see 08/15) 
   - dod/assume no connection at all 
      -> ask what to do when remote actions requested 
      -> these questions may be turned off 
   - ask gateway if it is connected 

These can be put in a world readable dir on the client machine and don't
confuse non 08/15 systems.  All on 1.) has to be explained so far that a
standard user understands what he does during install. Maybe they can
become default selection. The points on 2.) are for administrators and
can be described in a separate INSTALL file. 

Another thing is if someone really _wants_ a process running on a
gateway to the internet showing "hello, i'm connected". When there's a
firewall inbetween the clients and the gateway using e.g. socks, it
won't work. If the gateway itself is a firewall, the process will become
an additional security threat to e.g. exploits. So no administrator
might choose to make use of this feature. 
I really think checking if we are connected is a good idea, but for some
systems it might be good to have a force-connected (clients over
gateway) or force-not-connected option (dod). 

If someone using dod starts doing something remote, there could come an
appropiate popup asking what to do and switching to connected mode.
After a specified timeout (which may be a few seconds less than the
connection timeout) we could switch to force-not-connected again. 

So resuming: The interface will be a bit tricky, for we have to divide
into users who don't want to know anything about the technical crap and
the administrators of the network who should at least know the technical
details of their net. But i think we should avoid anything producing
dns-lookups, or at least have options to turn this off.


Regards,
  Holger Thon

[prev in list] [next in list] [prev in thread] [next in thread]