Server Skeleton

[Roman Baron <al...@ibm.net>]

  As u all knoww, I've started to construct a server skeleton.
 It's not based on the structure I published earlier, I hope to cover
the structure here.
 Also this message deals with problems I have in the programming area,
I'd like to
 recieve suggestions BEFORE I get to them.  ( Justin that's ESPECIALLY
for you )

 1. Server structure:
     a. The server is multi-threaded, by a User thread that handles the
users requests
     b. A machinePool class is responible for interpreting & forwarding
information
        as for multi-server config, It's also responsible for
connectiong / discon. servers.
     c. A machine class is the one that handles the Directives
hashtable, It's responible for
       loading it, as well as any other machine related stuff (Remote
server connections,
       etc. )
     d. Directive class, is either going to be splitted or left alone (
to Name & parametera)
       now that's an issue. We need either to make a Hashtable of
Hashtables (Directives
       per group), or split the directive ( to (name, group) And to (
parameters ) ).
       Justin: I'l try to include parameter type info, we'l need to give
another types,
       eg somethin like: t_Dir, t_YesNo, t_serverType and so on...
          ***** But!!!! *******
       I want to make the parser universial, eg it ONLY loads the
directives to mem and NOT further. I wan't to leave that to thhhe
applet, to increase flexibility ( U get what I mean? ).
     I'l again describe my mission on the Server more clearly:
   1. Directive Parser
   2. addParam, getParam, setParam, addDirective, getDirective,
remDirective, saveConfig, bootMachine, more.. on each level: User ->
MachinePool -> Machine.
   3. User interface ( I hope that's not SNMP! ;) ) ( Closed brackets?
So, I'm a C programmer! );
   4. Establish multi-machine communications
   5. Password auth. and locks
p.s. Locks I believe should be on a per file basis, cause some
directives depend on other, like dir maps and file types, and an
unplanned modification of one may be harmful.(eg. while another, the one
it depends on, is also modified ).

 **** For a while thou u all kept radio (e-mail) silence - why?
***********
  Regards all, Roman Baron alphax1@ibm.net

Re: Server Skeleton

[Justin Seiferth <se...@erols.com>]

Et al,


>      b. A machinePool class is responible for interpreting & forwarding
> information as for multi-server config, It's also responsible for
> connectiong / discon. servers.
>
I'd blow the multi-server functionality off for the moment.  If the
broker class I posted properly isolates the communications stuff and we
use a toolkit ala adventnet then we can tacklet this work at a latter
date- so let's ignore this for the moment (except for add the
appropriate fields to the directive class).


> c. A machine class is the one that handles the Directives
> hashtable, It's responible for loading it, as well as any other machine related stuff (Remote
> server connections, etc. )
>
 Not sure what is meant by this.  There should only be a few directives
(like on the order of a few hundred at most )  the overhead of a hash
table probably isn't worth the increased search speed.


>  d. Directive class, is either going to be splitted or left alone (
> to Name & parametera) now that's an issue. We need either to make a Hashtable of
> Hashtables (Directives per group), or split the directive ( to (name, group) And to (
> parameters ) ).
>
 I think the class definition of Directive needs to contain:
    - int name (enumeration used to represent the name but save a tiny
bit of space. comments and
                        blank lines are also a form of directive in this
sense)
    - String value
    - int valueType  (enumerated to represent boolean, list of IPs or
whatever)
    - String context (see the multi-server discussion above.  Stores
machinename:servername:scope.)
    - int lock (I think this is necessary on a directive basis)
There should be an instance of Directive for each line of all the
configuration files.  The primary "view" of these directives is then the
line-number sequence in which they appear within the configuration file.
You can just store these instances in a linked list- nothing fancy.
Here's an example of an instance.

Head->LineOne                                        ->LineTwo
                - 0     // represents a blank line    - 3
// represents ServerType
                - null                                        - "inetd"
                - null  // means innapropriate        - 3
// means string
                - www.disa.mil:httpd:global                  -
www.disa.mil:httpd:global
                - 0     // don't need to lock this!    -
0                // not being edited

->LineThree                                            ->LineFour
                - 4    // <DIRECTORY>                    - 19        //
AuthType
                - "/usr/local/etc/httpd/test"                  -  "LDAP"

                - 5    // means valid directory path        - 20
// means one of basic, dbm, LDAP, etc
                - www.disa.mil:httpd:global                 -
www.disa.mil:httpd:global:/usr/local/etc/httpd/test
                - 1    // somebody is working here        - 1         //
locked because directory is locked


->etc.

Clear as mud?

The applet only sends directives back- it doesn't really evaluate them
other than to restrict (in the GUI) the available choices to valid ones
where it can. It has to be this way to support scripted (via PERL, TCL,
etc) batch uploads of configurations.  It's up to the server to really
check to make sure we don't for instance give an IP address as the value
of the ServerType directive.  This check is the purpose of the valueType
member. The GUI will of course ask for values when it needs to display
them.

Harrie, any ideas on how a mib set up to handle this type comm should be
set up?

Justin






--
Justin Seiferth