The Virtual Gallery Initiative
About Source Docs Examples bottom
Docs


All of this is included in the /docs directory of the download

This is a breakdown of each object element in the client and server... Perhaps you wanted examples for how to use VGI


Server

vgid.o:

This is just an extended wrapper for the vgid class. It also handles the passing of connections to children processes, checking status and signaling the children through the use of the routines in child.c


vgi_server.o

This is the class definition (vgid) for the vgi server application. The class constructor sets the port, number of connections, number of keys and root directory to use. It handles the following:

1. parsing requests (where the requests are from is handled by vgid and its children)

All this is is analysing the input from the connection and determing what needs to be done which will either be add a user, serve a file to a connected user, or refuse the request.

2. adding users and assigning them a key.

When trying to add a new user, it asks the keyring to creat a new Key which is an ID number and encryption key. If none are available, the max users has been hit and a server busy is returned.

3. serving and validating files

When a connection asks for a file, the ID number is checked to see if it is registered. Then the coresponding encryption key is gotten. Before the file is encrypted and serverd it is validated first. This is done by a re-write of the file utilities which are stored in the misc2.cpp file. What it does is compare the file requested, by moving about the directory tree in the file equest. Then before opening the file it compares the final file location with the root directory of the vgi files. If we are in the vgi file root, the file is validated, else an error is returned. One of the things this prevents is a request for '../../../../../etc/passwd' and other sensitive files.

4. logging

This logs connections and displays them. Currently it is not up to speed with forking of
children and such, so connections are displayed as 0.0.0.0 but the files asked for are correct.


child.o: child.c include/child.h

This handle the parent/child communications. It has the routines for creation of children, info, restarting children, and signaling them. The creation and calling of them occurs in the vgid wrapper program.


misc2.o: misc2.cpp include/misc2.h

These are miscelaneous routines needed by other segments of vgi and vgid. They include the conversion of command strings to numbers and vice versa. The clearing of buffers. But most importantly it includes the file validation used to restrict file access to within the vgi root file directory.


random.o: random.cpp include/random.h

An random number generator used for id numbers and blowfish keys.

keyring.o: keyring.cpp include/keyring.h

While a simple linked list for holding multiple keys. It also holds the random engine for new keys/ids as well. It has the management for adding/removing keys, various locating functions, and the load keys functions which loads a specified number of keys for the server. To save on processor time, the keys are generated on load, then as users come and go the individual keys can either be expired or shifted to a new user, depending on the sysadmin.

key.o : key.cpp include/key.h

Simple class storing id numbers, related key and a wrapper for the blowfish encrypt/decrypt functions.


blowfish.o: blowfish.cpp include/blowfish.h

All this does is handle the seting of the blowfish key and the encrypt/decrypt of a block. It's called by the key class for file handling in vgi and vgid.




Client

vgi.o : vgi.cpp

This is the heart of the client. The various system parts include.

objlist vgi_object_list; /* Linked list of objects to show */
lightlist vgi_light_list; /* Linked list of lights and variables */
parser a_parser; /* Parses the markup language to data */
vgi my_client; /* Handles file conection + cryption */
viewer my_viewer; /* Handles perception and movement */
GLuint Master_List; /* Display List for compiled objects */

Most of this file is GLUT functions to control the viewing window, which functions to use during the event loop, and the onscreen menus (right click). It accepts command line entry in the from vgi 192.131.123.11 test.vgi. If any are not secified, the defaults are index.vgi and 127.0.0.1 respectively.


The Init function is where most of the interesting stuff takes place. A quick breakdown follows
1. Parser is informed where the vital system functions are by reference.
2. The Parser then parses relavent data (see parser.o) and creates a linked list of objects and a linked list of lights.
3. All of needed images are gotten. Note this is after the parser is done. This is done through the linked object list created during the parsing. They are stored in the cache in encrypted form.
4. The Overall Object variables are set
5. The Overall Light variables are set.

6. A compiled Display list is created from the object list. This is where the images are finaly decrypted and stored as textures. A GL Display list is used rather than the object linked list draw_list function because of speed optimization.
7. The lights are set using the linked list draw function.

The event loop is fairly straightforward. Passing mouse functions to MouseMove and MouseEvent. Passing keyboard to Key and Special Key, etc...

vgi_client.o:

The is impimentation the vgi class. All it is responsible for is the connection to the vgid server, negotiation of ID, Keys, and file requests. It does NOT handle file decrypts.

viewer.o: viewer.cpp

Is exactly what it sounds like. It handles the movement and viewing transformations. There are two viewing modes, Polar and Flying. Polar roates around a given point from all the axes, while Flying provides a flight simulator experience. These replace the usual GL viewing functions.

misc2.o: misc2.cpp include/misc2.h

These are miscelaneous routines needed by other segments of vgi and vgid. They include the conversion of command strings to numbers and vice versa. The clearing of buffers. But most importantly it includes the file validation used to restrict file access to within the vgi root file directory. This does not do much in the client side, but it never hurts on shared systems.

keyring.o: keyring.cpp include/keyring.h

same as server. Though technicaly only one key is used for the site viewed, this allows for future upscaling of multiple keys and sites.

key.o : key.cpp include/key.h

same as server

random.o: random.cpp include/random.h

same as server.

blowfish.o: blowfish.cpp include/blowfish.h

same as server.


objlist.o : objlist.cpp

A linked list of all the objects in the parsed vgi file. It also contains an older draw_list function that has been replaced by a display list to increase performance.

canvas.o : canvas.cpp

This is a class to contain all the relavent information about the images to be used as textures. It has a linked list of the texture vertex pointers, not the actual vertex pointers but the texture ones that tell it how to stretch and pull the texture in relation to the real vertext pointers.
It also stores all the GL information such as filtering, image mode, size, how to wrap it.

object.o : object.cpp
This is the big data class of the vgi client. For starters it stores all the vertex pointers in a linked list that define where this object is to be placed. It also contains a canvas object for the image associated with its object. In addition it holds various file information about the image, for loading after the parse.


lightlist.o : lightlist.cpp

A linked list of light objects. Contains the draw_list function for drawing the lights.

light.o : light.cpp

A data class for storing the GL information about various light objects. Information such as direction, exponent, coloring is all stored here.

pointlist.o : pointlist.cpp

A small linked list for holding 4 point vertex info (both vertex and texture points)


readtex_buf.o : readtex_buf.c

Assorted functions for reading buffered sgi/rgba file image info, as opposed to readtex which requires a file descriptor. This is used because the information is coming from a decrypted buffer rather than a hard drive file. Yes this means that all image loaders (jpg,png etc...) will have to be re-written for this program. Then it returns a Texture map of the image for use in the GL. The texture name is stored in the canvas class.

readtex.o : readtex.c

Loads a sgi file into a texture map.

parser.o : parser.cpp

This is a large function split over a few .cpp files for easier management. They include

parser.cpp -Main functions
parser-data.cpp -Tag manipulation functions...

int get_tag(int start_pos); /*Pulls next complete tag */
int split_tag(); /*Splits one data entry tags */
int get_data(int start_pos); /*Next entry in multi-data tags */
int get_data_cap(int start_pos); /*Same as get_data but capitalize */
int get_points(); /*Extracts Float Data Pts from string */

parser-head.cpp -Parse the head and gather global information
parser-light.cpp -Parse inbetween the light tag and create an object for it
parser-object.cpp-Parse the object tag and create an object for it

The first thing the parser does is run first_pass, which capitalizes anything not in quotes plus removes spaces and special characters (Line Feeds etc)
Then it parses out head information for the global state variables and procedes onto the body for the object and light tags. All temporary data such as current tag, values, etc are stored in the class buffers/registers which allows for easier passing around to different functions