Technology Development

CONSULTING AGREEMENT



AN AGREEMENT BETWEEN Comat System Solutions Private Limited, India having its office at 1-1/8, 2nd Main, 11th Cross, Vyalikaval, INDIA, AND CNM Network, 1900 Los Angeles Avenue, 2nd Floor, Simi Valley, CA 93605 to produce a work tentatively Provisioning System



Whereas, CNM wishes to engage Comat's services as specified herein, and Comat is ready, willing and able to undertake the rendition of services.



Now, Therefore, in consideration of the mutual agreements herein contained, the parties agree as follows:



1 OWNERSHIP



1.1 CNM will copyright the Provisioning System in its own name in

conformity with copyright law and with the laws of other countries as

necessary. CNM will have complete and exclusive right of ownership of

the product and all the associated programs, source code, and the data

developed for the purpose.





1.2 Comat agrees to assign and does hereby assign CNM the entire right,

title and interest in and to all software, inventions and designs made

by Comat, alone or with others, which arise out of or pertain to the

services rendered under this agreement, together with any patents

and/or copyrights as may be obtained on the software, inventions and



1.3 It is understood by CNM that Comat may perform consulting services for

others; providing however, Comat shall not, during the term of this

agreement and a period of six (6) months thereafter, aid any

individual or organization competing with CNM regarding matters

related to this agreement.





2 DESCRIPTION OF WORK



2.1 CNM shall retain Comat and Comat shall do work in the field of

software development. Comat will use its best efforts in the

accomplishment of the software engineering task and goals in building

and refining software for CNM.



2.2 Work will be done in accordance with the Systems Specifications

Document as attached,





3 RESPONSIBILITIES OF COMAT



3.1 Comat will be responsible for developing software with no known bugs.



3.2 The main responsibilities of Comat, carried out in consultation with

CNM include project management, detailed design, programming, testing,

and production of a portable source code. The main tasks are to

design, implement, deliver the final product with complete source code

and documentation to CNM.



4 DURATION





4.1 The duration of the contract is estimated to be a period of four (4)

months beginning May 12, 1998. During this period Comat will assign

resources necessary to complete its responsibilities as described















5 CHARGES AND EXPENSES



5.1 For this project, CNM will pay Comat a fee not to exceed $37,900 and

the actual cost will be determined at the completion of the project.



6 PAYMENT TERMS



The total cost of the software development performed by Comat shall be

funded by CNM as follows:



6.1 Comat will invoice CNM on a deliverable basis. The final invoice will

be paid within 10 days of CNM approving final product.





7 DATA SAFEGUARDS



7.1 Comat agrees to make a prompt and full disclosure to CNM, the details

of all inventions, discoveries and improvements made or conceived by

Comat, alone or with others, which relate to the subject of matter of

agreement with CNM.



7.2 Nothing in this agreement shall be construed or implied to create a

relationship of partners, agency, joint venture, or of employee and

employer. As an independent contractor, the commitment on CNM under

this agreement is the performance and fees limited to paragraph 2.



7.3 This agreement cannot be modified in any way except in writing signed

by both parties.



8. TERMINATION



This agreement may be terminated immediately by a written notice if:



8.1 Having given notice of a breach of this Agreement, whereby either

party has failed to provide the services to continue full and active

duties under this Agreement, and whereas the other party fails to

remedy the breach within a reasonable period (and in any event no

longer than 30 days after the notification).





-------------------------------- -------------------------------------

Fred Rice S.R. Rangan

CNM Network Comat System Solution Private Limited

1900 Los Angeles, 2nd Floor 1-1/8, 2nd Main, 11th Cross,

Simi Valley, CA 93065 Vyalikaval, Bangalore







1 INTRODUCTION 3 - --------------------------------------------------------------------------------



2 MODULES 4 - --------------------------------------------------------------------------------



2.1 SERVER INTERFACE 4 2.2 REQUEST SERVERS 4 2.3 FAILED TASK QUEUE 4 2.4 SUPPORT MODULES 4



3 TRANSPORT MECHANISM 5 - --------------------------------------------------------------------------------



4 MODULE FUNCTIONALITY 6 - --------------------------------------------------------------------------------



4.1 SERVER INTERFACE 6 4.1.1 Virtual Web Inteface 6 4.1.2 DNS Interface 6 4.1.3 Incoming Mail Interface 6 4.2 REQUEST SERVERS 6 4.3 FAILED TASK QUEUE 7 4.4 SUPPORT MODULES 7 4.4.1 Machine allocation for new/ altered domain. 7 4.4.2 Domain is available 7 4.4.3 Domain registration confirmation by InterNIC 7 4.4.4 Check user info for Empty fields 7 4.4.5 C heck user info for invalid data 7 4.4.6 Saving and retrieving demographic information. 8 4.4.7 Making billing entries. 8 4.4.8 Administratio n Interface 8



5 INTERFACES 9 - --------------------------------------------------------------------------------



5.1 PERL INTERFACE 9 5.1.1 Domain Interface 11 5.1.2 Virtual Web Interface 15 5.1.3 Mail Interface 16 5.1.4 FTP User Interface 17 5.1.5 Mail user Interface 18 5.2 INTERFACE WITH SERVERS 19 5.3 SQL INTERFACE 20 5.3.1 Table Domain 21



6 DATA STRUCTURES 24 - --------------------------------------------------------------------------------







7 CLASS STRUCTURES AND PSEUDOCODE 26 - --------------------------------------------------------------------------------



7.1 SERVERINTERFACE (BASE CLASS) 26 7.2 USERNAMEINTERFACE (DERIVED CLASS) 28 7.3 DOMAININTERFACE (DERIVED CLASS) 28 7.4 DNS _INTERFACE (DERIVED CLASS) 28 7.5 VIRTUALWEBINTERFACE (DERIVED CLASS) 28 7.6 INCOMINGMAILINTERFACE (DERIVED CLASS) 28 7.7 REQUESTSERVER ( B ASE CLASS) 29 7.8 USERNAMESERVER (DERIVED CLASS) 30 7.9 DOMAINSERVER (DERIVED CLASS) 30 7.10 DNS_SERVER (DERIVED CLASS) 31 7.11 VIRTUALWEBSERVER (DERIVED CLASS) 31 7.12 INCOMINGMAILSERVER (DERIVED CLASS) 32 7.13 FAILED TASK QUEUE 32 7.14 MACHINE ALLOCATION FOR NEW/ ALTERED DOMAIN. 32 7.15 DOMAIN IS AVAILABLE 32 7.16 DOMAIN REGISTRATION CONFIRMATION BY INTERNIC 33 7.17 CHECK USER INFO FOR EMPTY FIELDS 33 7.18 CHECK USER INFO FOR INVALID DATA 33 7.19 SAVING AND RETRIEVING DEMOGRAPHIC INFORMATION. 33 7.20 MAKING BILLING ENTRIES. 33 7.21 ADMINISTRATION INTERFACE 33



8 TERMINOLOGY 34 - --------------------------------------------------------------------------------



8.1 TRANSACTION 34 8.2 TASKS 34 8.3 PROVISION ING SERVER 34 8.4 SERVERS 34 8.5 USER 34





PROVISIONING SYSTEM



1 INTRODUCTION



Provisioning system will be a software that will permit users to set up Web, FTP, mail servers and manage them through web pages. Provisioning system is being currently viewed as a service to be provided by CN M where users will pay CNM for services like Web Server, FTP Server etc that would be set up on CNM infrastructure.



The aspect of this system we are working on starts with a PERL interface calling up the system with information provided by user. This info rmation is used for creating, editing or terminating various services. The system will interpret the requirements and send messages to various servers which actually provide the service required. As these servers can only be configured from a process on t h e same machine, the provisioning system will run a process each on these servers to pick up the requests and configure the server on basis of the request. The requests fall in two broad categories first deal with setting up and managing domains and the se c ond category deals with setting up and managing users on a domain. As any interaction between the user and provisioning system can involve more than one computers, there is a strong requirement to have a error handling mechanism in the system which will l e t a task be completed later if it fails on the first run. This would require some sort of extensive logging of all transactions and maintaining information on current state of each of these transactions. All services provided to the customer will be bille d . The provisioning system will have to inform another software about the services demanded by the customer so that appropriate billing can be done. System administration and Maintenance of the software will require facilities to provide command line input s to the software and some method of controlling the monitoring information provided by the system.



The system can be visualised as a set of set of server management functions which are called either in a predefined sequence (while executing a specific use r request) or individually at random (while executing previously failed tasks. As all tasks (I believe) originate with user requests, the user request appears to be the correct starting point at first glance. However, if we take task execution failures in to account and want to build in an ability to complete failed tasks at a later time, the server management routines become the central focus of the design.







2 MODULES



2.1 SERVER INTERFACE



The server interface routines will broadly belong to these ca tegories: 1. Domain Name 2. User name 3. Virtual Web Server 4. DNS 5. Incoming mail server Of these routines, the first two do not involve communication with other machines, and the final execution will happen on the provisioning system machine i tself. The balance requests will be forwarded to the respective servers (for create requests, only the destination machine type is specified). To maintain uniformity and expandability, even the first two requests will use the same mechanism, except for th e fact that the sending and the receiving machines will be the same. The specific transport mechanism used will be restricted to small piece of code and all other routines will simply submit data for transfer without bothering about the transport mechanism used.



2.2 REQUEST SERVERS



This module is a separate process, which will run on a different machine and will receive requests from the provisioning server. The requests will be interpreted and then passed on to the server being hosted by the machine. The result will be converted into a data packet and transmitted back to the server. This module also has transport mechanism dependency, which will also be restricted to a small piece of code. These servers will need the added capability of being able to wor k with different versions of the client software at the same time.



2.3 FAILED TASK QUEUE



Any non-critical tasks that fail during the first run will be left in a database to be re-attempted at specified intervals. This is essentially a thread, which will look for failed tasks and try to complete them. If the thread succeeds to complete the task, then it will mark the record as completed. This thread adds the feature of graceful and selective degradation of the performance to the system. As a result, even if some servers are not able to process user requests, these requests can be left in a queue for later handling.



2.4 SUPPORT MODULES



1. Domain is available 2. Domain registered confirmation from INTERNIC. 3. Check user info for

- Empty fields

- Invalid values 4. Saving and retrieving demographic information. 5. Retrieving billing rates. 6. Making billing entries. 7. Machine allocation for new/altered domain.







3 TRANSPORT MECHANISM



The term Transport mechanism has been u sed to refer to the complete data interchange/handshake mechanism between two processes. The transport mechanism to be used will have to be capable of supporting the following features: - - Version control - - Version negotiation - - Multiple res u lt values The transport mechanism being considered is DATA STRUCTURE WITH VERSION INFORMATION. Here, all data structures passed around will have major and minor version numbers. Additionally, the data structures will carry the total data size as one of th e fields. The structure can hold integers, real numbers, fixed sized strings etc, but for variable size array, the technique used will be to store the array size and its offset from the beginning of the data structure. The Data structures used will have a h ierarchical growth in structure, with all related structures having the same common basic fields. This will permit a data structure pointer to be type cast as a higher level data structured and read or written to without bothering about its actual format.







4 MODULE FUNCTIONALITY



4.1 SERVER INTERFACE



The server interface will be a set of classes inheriting from a common base that provides the basic functionality and interface format. The base class will have stubs and generic code for 1. Create, Ed it and Delete functions. 2. Logging - Basic functionality of writing logs with time stamp and

incomplete flags raised and upgrading logs to indicate safe completion of

the request. Logs will be written and flags set before any transmissions

are made to protect the system from irrecoverable failure during call

3. Data Transfer. 4. Error Handling For almost all inherited classes, the following functionality will have to be upgraded 1. Create, Edit and Delete Functions. 2. Logging 3. Data Transfer The classes that will derive form Server Interface and the additional functionality they will provide are



4.1.1 VIRTUAL WEB INTERFACE



Space required.



4.1.2 DNS INTERFACE



Domain Names, IP Addresses of machines hosting various services.



4.1.3 INCOMING MAIL INTERFACE



Number of users, User accounts, account resources.



4.2 REQUEST SERVERS



Request servers will follow the general framework of Server Interface classes. The base class will hold the stubs and transport functionality while the inherited classes will complete the stubs and upgrade functionality of the transport mechanism.





Additionally, the request servers will support version negotiation and version checking of the data received. The way data is actually handled will be decided by the derived classes and the derived classes are free to limit the version ranges supported.



Care will need to be taken so that exceptions are properly caught and suitable message is transmitted to the calling interface.







4.3 FAILED TASK QUEUE



The failed task queue depends on the logging mechanism of request servers for input. All calls that fail during initial execution are flagged as incomplete and will be left for this queue to complete later. This queue will scan the database for incomplete tasks and verify that their dependency conditions have been fulfilled (if any). It will then try to execute that task and if successful, flag the task as completed. This queue can run on the provisioning system as a t h read on the process. The system will have functionality to send alarm to administrators on exceeding predefined failure limits. Functionality may be added here to send message to the user about completion of the account setup if any of the setup tasks wer e left for the queue.



4.4 SUPPORT MODULES



4.4.1 MACHINE ALLOCATION FOR NEW/ALTERED DOMAIN.



Multiple machines will host each service. When a new domain is registered, the services required for that domain will have to be allocated to one of the machi nes hosting that service. This module will decide which server will host each of the services, reserve capacity and make suitable log entries. If a domain's requirements are altered to the extent that one or more of the servers' capacity is exceeded, the server for that particular service will have to be reallocated. This module will also handle these reallocations.



4.4.2 DOMAIN IS AVAILABLE



This module will check the local and the InterNIC database for availability of a domain. The InterNIC check is a simple whois function call to find out whether the domain name is in use. The domain could be registered with a third party or with CNM servers (The DNS servers might be more than the regular primary and secondary DNS servers). The additional local chec k is done for two reasons 1. If the domain name is being processed for another user, then it will

definitely not be available for the current user. 2. As the local login names are domain dependent, letting two users apply for

the same domain can cause login clashes that will be very hard to resolve. The local check will involve checking the list of local domains (a domain here may still be under process by InterNIC) and list of pending domain requests.



4.4.3 DOMAIN REGISTRATION CONFIRMATION BY InterNIC



Domain registration is an asynchronous and slow process. The confirmation is expected some hours after the request has been sent to InterNIC. The confirmation is in the form of an email. This e-mail will have to be parsed to interpret the do main name actually registered and the time by which it will become operational. Subsequently, this function will set the necessary flags to indicate the new status of the domain registration request.



4.4.4 CHECK USER INFO FOR EMPTY FIELDS



Although th e front end will do a data validity check to make sure that all necessary data is present, this level would also run a check on the data that is vital for the transaction to complete. This level will not bother with data that is needed only for demographi c information. The primary reason for running this check here is that once this check has been completed, the data availability for the transaction completion is assured. Another aspect of check at this level is the check on data validity.



4.4.5 CHECK USER INFO FOR INVALID DATA



This check tries to locate invalid data like wrong or invalid credit card details, unacceptable numbers supplied for resources like disc space, bandwidth requirements, number of users etc. A lot of decisions taken at this level will depend on the system policy.







4.4.6 SAVING AND RETRIEVING DEMOGRAPHIC INFORMATION.



The demographic information collected will be written to a database and possibly associated to the domain. Demographic information, for display, processing and updates, will be retrieved by this module.



4.4.7 MAKING BILLING ENTRIES.



Non financial billing information will be handled by this module. All purchases/ purchase alterations demanded by the customer will result in a record being generated by this mod ule. The billing module will use these entries to generate the financial impact information.



4.4.8 ADMINISTRATION INTERFACE







5 INTERFACES



The provisioning system that we will be working on will have three interfaces. The program will primarily i nteract with the outside world across these interfaces. These are: 1. Perl program interface. 2. Interface with servers. 3. Interface with SQL server and tables. These interfaces constitute the most rigid aspect of the design. Any alteration of thes e interfaces requires proper coordination with the team in Simi Valley. Each of these interfaces has a different communication mechanism and they are explained below.



5.1 PERL INTERFACE



The Perl interface is a programming interface. Here, the Perl progra m (to be developed and maintained at Simi Valley) connects to the provisioning system and issues commands in the form of Data Blocks. These commands are very similar to the commands issued by the provisioning system to the server side modules. Consequentl y, large parts of data structure will be reused between Perl/Provisioning system interface and Provisioning system/Servers interfaces. The Perl interfaces will call up provisioning system on IP port 48000. The data structures that will be passed are



struct T_PERL_INTF

int nVersion;

long lBufferSize;

int nCommand;

int eServerType;

char szDomainName[32];

char szAdminUserName[32];

char szAdminPassword[16];

char szUserName[32];

char szUserPassword[16];

int nReturnValue;

char szErrorMsg[128]; ; This is the primary building block for all communication structures. This structure contains Version information, full command description, Domain name, Admin user name and password. All subsequent structures are more specific and are described along with interface functionality description. A few fields whose behavior remains constant are explained here and will normally not be described in other sections. The y will have further description in other sections only if their immediate behavior differs from the description provided here or values to be used are specified. nVERSION: Holds the version number of the data block. This version number

permits clients with different version numbers to communicate with the same server. This field is filled on input. lBUFFERSIZE: Holds the size of the complete buffer. This field will become

critical when the data passed will contain variable length fields. This

field is filled on input and output. nCOMMAND: Holds the actual command to be executed. This field is filled on

input. The permissible values are: - - CMD_CREATE - - CMD_QUERY - - CMD_ALTER - - CMD_DELETE - - CMD_CHECKAVAILABLE nSERVERTYPE: Holds the type of server that the command is meant for. This field

is filled on input. The permissible values are: - - SERVER_DOMAIN - - SERVER_VIRTUALWEB - - SERVER_MAIL - - SERVER_USER_FTP







- - SERVER_USER_MAIL



szDOMAINNAME: Holds the domain name. For all commands except domain creation,

this holds the domain name being referred to. For domain creation, this

holds the domain to be created. This field is filled on input. szADMINUSERNAME: Holds the administrator user name. This field is filled on

szADMINPASSWORD: Holds the administrator user password. This field is filled on

szUSERNAME: Holds the user name when individual user accounts are being

manipulated. For server level commands, this value is not used. This value

is filled on input. szUSERPASSWORD: Holds the user password for the user account. For server level

commands, this value is not used. This value is filled on input. nrETURNVALUE: Holds the return value. This field is filled on output. The

following values are common return values - - SUCCESS: Call successful. - - UNKNOWN_ERROR: Error text is returned in szErrorMsg. szERRORMSG: This field holds error message if the Return Value does not

suffic ...