WebServer Design Use Cases

Web Server Design Use Cases

The following use cases support a One-to-One protocol model:

Actors and Associated Goals:

Client Goals - 

1. Requests data files
2. Receives data files
3. Executes SMF auto-installer method
4. Verifies data integrity

Transport Mechanism Goals - 

1. Transmits requests from client to server
2. Transmits requests from server to client
3. Provides required performance reporting
4. Reports success or failure of transmission.

Server Goals - 

1. Receives requests for data files
2. Sends requested data files
3. Determines the AI manifest for each specific client
4. Receives request for solaris.zlib
   1a. Sends solaris.zlib file
5. Receives request for solarismisc.zlib
   2a. Sends solarismisc.zlib file
6. Receives request for configuration files
   3a. Sends configuration files.
7. Receives request for AI manifest
   4a. Processes  to get an AI manifest to use. ( for either static or derived profile manifest)
8. Sends AI manifest

Additional Considerations for Peer-to-Peer (P2P) interactions:
In the case of transport mechanisms that rely on P2P interactions, the line between "server" and "client" is somewhat blurred. With that in mind, the following lists the modified goal set for a P2P set-up.

Goals for P2P Clients:

• All goals for traditional clients plus:

1. Receives requests for data (files or file segments)
2. Sends requested data (files or file segments)

Goals for the AI Server in a P2P set-up:

• Not the same as standard AI server

1. Manage new clients and introduce them to peers with desired data
2. Manage old clients and introduce them to new peers that will end up with desired data
3. Act as a peer for clients, in the case of data that is not available from other peers
4. In the case of dynamically generated data, or other data that cannot be delivered feasibly in P2P fashion, act as a traditional server 

The following information outlines the steps for a one-to-one protocol transport interaction:

Use Case 1:  A single client requests data and a server resopnds and delivers the requested data.

1. Initial boot program is done by TFTP. Client requests Pxegrub from the server and the server returns the Pxegrub file.
2. The Pxegrub file is a booter. The pxegrub file makes the request to the server for the menu.lst file. This is the only configuration file transferred at this point.(Are 1 and 2 effectively one step - Sundar will check)
   3.This is TFTP boot. The menu.lst file contains the information that allows the
   client to request the boot archive file, and the server delivers the file.
3. After the boot archive is downloaded to the client, the client boots and begins to run Solaris.
   5.After Solaris boots, it goes thru SMF methods, and we access the live-fs-root service to begin the process of accessing the solaris.zlib and solarismisc.zlib. The menu.lst (Pxegrub looks at all of the options of menu.lst and exports them as an option node on the dev info tree).The location of the install programs is in the menu.lst file and made available thru Pxegrub.
   6.The SMF method, auto-installer, retrieves the AI manifest. The auto-intaller method discovers location on the network and gets the manifest.

Use Case 2: Multiple clients request data and a server responds and delivers the requested data (using the same examples).

The steps are the same between client and server.

What needs to be evaluated are the issues that could occur when we try to scale up.

Use Case 3: Peer-to-Peer Transport Mechanism

1. Initial boot done by TFTP. Client A request Pxegrub from the server, which returns the Pxegrub file directly.
2. Pxegrub requests menu.lst.
3. TFTP boot begins. Requests for archive files occur.
4. Client contacts TFTP server for list of clients with the desired archive(s). Client initiates peer-to-peer transfer of archive with list received.
5. During this process, a second client (B) also reaches this stage. Client B requests archive data from client A (among others, potentially).
6. Booting continues. The peer-to-peer transfer process is initiated again when the AI manifest is requested.
7. Booting continues per usual.

X86 client - Server steps

SPARC client - Server steps