RFC

[Gregory McLean <gregm comstar net>]

The following is a rough draft of a current proposal. Comments appreciated 
and
desired.

---- CUT ----
	    Simple Network Database Notification Protocol.

Abstract

   The Simple Network Database Notification Protocal (SNDNP) is designed 
to
   support multiple client syncronization to remote servers. This protocol 
   has been designed so that any transport method may be used as well as 
any
   storage method on the server side may be used. The protocol is further 
   only concerend with the actual client server communication.

Introduction

   One of the big stumbling blocks in gxsnmp thus far has been how to keep 
   the database of all the hosts/networks and other collected data in 
sync.
   This presents a tricky problem that only one solution really will solve 
   this and allow further development of the various pieces that make up a 
   good managment solution. The following is a rough draft of the current 
   propsal please take the time and read through and comment on it. We 
will
   need an  implementation before futher work can be acomplished 
   (without wasting time).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENED", "MAY" and "OPTIONAL" in this 
   document, when they appear in all capital letters, are to be interpreted
   as described in RFC 2119.

Protocol

   The server shall be responsible for all communication with the database,
   The clients, be it the gui application, the network discovery agent, 
   the trap monitor or any other future component connecting to and 
   interacting with the server shall only be concered with the client 
   server communications.  

   Each operation to the server shall be defined in the following way:
     - Each operation is a whole transaction.
     - Each operation has a rollback function.
     - The database update shall only occur once the complete operation
     has been received from the client. If the client disappears in the
     middle of an operation the rollback procedure, if applicable shall
     be invoked.
   A rollback operation shall not be needed for a read operation.

   The server furthermore shall be responsible for notifications when the
   underlying resources change. This will allow the remote deployment of 
   any client that needs to be kept in sync with the database.

   The clients shall be responsible for connecting to the database and 
   registering which resources they are intrested in for when the 
resources in
   question get updated. Clients shall also register the preferred method 
of
   update notification. Available update notifications shall be one of the 
   following:
	1. Plain notification. 
	  Just notify the client that the resource has been updated and it 
	  should reload at the next opertunaty..
	2. Notification with updated data. 
          This type of notification will have the notification and the 
updated
	  data packaged along with it.
    Client connections to the server shall be persistant for the lifetime 
of
    the client. Upon server crash or disconnection it will be up to the 
    transport method to notify the client/server of the condition of the 
    connection. Clients should be designed to handle such failures of the 
    server gracefully.

    Any encryption of the data shall be the responsiblity of the transport 
    method used. The protocol design itself shall not interfear with the 
use
    of Secure-Socket-Layers or any other encryption method. This will all
    be handled transparently at the transport level.

    Authentication shall be a simple username / password pair or a 
challenge
    response sequence.

    The following commands shall be implemented in the server (at a 
minimum)
    get     -- Retrieve resources from the server.
    put     -- Store new resources on the server.
    update  -- Update existing resources on the server.
    delete  -- Delete resources from the server.

    The following commands shall be transmitted to the clients as needed.
    notify  -- A resource has either been updated or deleted.

    Distributed servers shall connect to a specified master server in the
    interest of keeping the protocol and resulting code simple.

--- CUT ---

Thank you for your time.


Gregory McLean          |"With sufficient thrust, pigs fly just fine." 
RFC1925
ComStar Communications  | programmer / analyst | icq: ! | 770.485.6016
Work:<gregm@comstar.net>| Play: <gregm@gxsnmp.org> or <gregm@gnu.org>
----------------This is my opinion, All MINE! I tell you------------------