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

List:       kde-devel
Subject:    RE: Little Summary of "Daemon for managing dialup internetconnec
From:       "Bjoern.Kahl" <Bjoern.Kahl () kiel ! netsurf ! de>
Date:       1999-06-28 11:02:19
[Download RAW message or body]


 Hallo !

 Matt : You are some minutes faster than I :-)
        Have started writing about more-or-less the same you wrote
        just a few minutes ago.

 (should this also go to gnome-list ?)

 (Personal note:
  Due to hardware failure, I lost any mail (and lots of more data) send
  to me between Friday 15:00 MEST (last success mail-read) and Sunday
  morning (next try to download mail, interrupted by dying IDE-Controller
  at home.) )
 
On 28-Jun-99 Matt Koss wrote:
> 
> Basically I wanted to make a signal / slot stuff for informing apps
> about the connection and additionally to have a possibility to request
> close connection.
> 
> The proposed approach :
> -------------------
> We can simply create a wrapper around NetMgr, let's say a class called
> KNetMgr, which would use NetMgr methods to query a connection watcher,
> and emit the appropriate signals. KDE apps would then have to create an
> instance of this class and connect the signals to custom slots.

 It is the way I want to go. You may have read my answer to Waldo
 Bastians mail to both, gnome- and kde-devel-list, in which he
 suggested two setups (Message-ID: <3773538A.C5A55AC9@ens.ascom.ch>).
 I would prefer the first one. 

 BTW: started writing a GUI for NetMgr. Anybody know a working
      gui-builder ? kbuild doesn't compile for me. 

> This general class is needed, because app should not have to keep the
> information about the type of connection.

 I don't understand this line. what do you mean with "connection"
 here ? How to talk to NetMgr ?


>>> "Bjoern.Kahl" wrote:
>>
>>>>  What I wrote is supposed to be a generall, systemwide
>>>>  connecting-service. using X-Based thing will kill one of its
>>>>  design-goals: prevent timebased connecting and disconnecting 
>>>>  from interrupting hand-made connectings:
> 
> The proposed approach would conform to this, KDE apps would request /
> close connection through NetMgr and if the connection is already here,
> nothing would happen, as well as request for closing wouldn't close
> connection if some app is still registered with NetMgr.

> The above problem will be probably not present in home / one-user
> systems, but the proposed approach would work in all environments.


 (-: The problem (unexpected closing by some application) *is*
     present in home / one-user systems
     (prof by example : my system :-)) )

> Kcm module would be used for configuring all features of NetMgr. User
> could specify e.g. kppp or kisdn for connecting / closing.
> I guess that this would require some more cooperation on kppp / kisdn
> side in order to cleanly open / close connection ( kppp -k is not
> enough ). This applies also to handling errors when connecting.

 Yes.
 Connecting & Errordetection: See (long) note at bottom of this mail.
 (Please, read that note, may answer some questions.)


> Also requesting / closing of connections should be think out very
> carefully maybe configuration on per-app basis ?

 This is really critical. Each Aplication using NetMgr should be required
 to let the user disable auto-connecting and to let the user explicitly
 confirm an connectionrequest. Perhaps as a radio-button-choice :
 "auto-connect" <-> "ask for connection" <-> "don't try to connect" 

 It is surely nothing NetMgr has to deal with. How to use a service
 is the only responsebility of the application using that service.

 (Backgroundinfo: In germany, each successfull dial cost at least
  12Pf, even if you are only 2 seconds connected. After that,
  (depending on day-of-week and time-of-day) each startet minute
  costs more or less an other 12Pf.)


 Some examples how applications can behave:

 Especially for short-time actions (like check for mail) it might
 be usefull, to wait until some other task initiates a connection.
 As soon as the connection is up, a mailclient may request also
 a connection (to hold the existing one) do its transfer, and 
 drop the request. This could be repeated serveral times, as
 long as there is a connection (lets say: all 3 minutes). If
 there is no connection, the mailclient may try to connect in
 longer time periods (lets say: all 2 hour) (or, of course, when
 the user presses a "checkmail" button). Other application can
 then do the same trick, traveling on a its connections.

> Another thing is starting of the NetMgr server. This would be probably
> also configurable from kcm module - whether should it be started
> automatically at the login or not (system could have it already
> running, even before entering X)

 Next update (ready on my zip at home) comes with an
 SuSE-startscript to be inserted in /sbin/init.d/rc?.d .

 Expect this to appeare in CVS-kdenonbeta this evening.

> BTW, is NetMgr suitable for ISDN connections ?
> I am writing kisdn everywhere, but I still don't know if it can be used
> here.

  Yes.

  (Please read:)
  Some Notes on how it works:

  NetMgr can do *every* dialup-connection that can be triggered via a
  shell-command (... AFAIK all currently available connection-types
  fullfill this requirement) (I use only ISDN at home.)

  Some lines above you talk abaut errorhandling:

  Connecting works this way:

  NetMgr fork()s a child, exec()s the configured shell-command for
  connecting, and wait until a special client (called "isonline")
  registeres and reports a successfully established connection.
  Currently "isonline" (and "isoffline" for disconnecting) sits in
  /etc/ppp/ip-up (resp. ip-down). /etc/ppp/ip-up gets called
  by (i)pppd when ever the link comes up, and ip-down is called
  when the link goes down.

  Disconnecting works the same way:

  NetMgr fork()s a child, exec()s the configured shell-command for
  disconnecting, and wait until a special client (called "isoffline")
  registeres and reports successfull disconnecting.

  Failure-detection:

  Both actions setup a timer. If timer expires, connecting (or
  disconnecting) is considered failed. Clients which have requested so,
  gets informed about failure (or success) via the NetMgr-notify-system.

  The whole think is asyncronous:

  "NetMgr_requestlink(NETMGR_CMD_ONLINE)" returns immediatly. An
  application has to wait for Notify-packet of type "online" or do
  (ugly) busywaiting via NetMgr_requestlink(NETMGR_CMD_CONNECTIONSTAT).


  Bjoern


-- 
+-------------------------------------------------------------+
| Björn Kahl       +++   <bjoern@hp1.ang-physik.uni-kiel.de>  |
| Raum :  II 204   +++   Tel. +49 431 880 3934                |
| Institut für Experimentelle und Angewandte Physik, Uni Kiel |
+-------------------------------------------------------------+

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