Keshav's Kids, Directory service

2. Accomplishments

Java client classes

Developed client-side Java API to handle all communications with Directory Services server. Transparency is the key when it comes to client-server model API's. To accomplish the notion of transparent operations our first step was to determine all possible uses other teams would be expecting our API to perform, and then implement this list of functionalities in a generalized accessor method style. In practice it was found that we were unable to preempt all of our fellow teams and were forced to make changes to the API. These changes were however rather small and involved only adding conference support methods, and the credential verification method. The API was designed with the idea of treating the information stored in the Directory Services database as if it were on a local disk. The API user is never required to perform any type of network or socket manipulation outside of specifying the address and port number of the Directory Services server. This abstraction of treating the database as if it were local aids in the ease of use and ease of learning for the API user. As per a request of the Signalling team, most of the Java API was ported to C++ for use on the gateway system.

To provide ease of testing and a useful interface to interact with the more complex functionalities we've implemented, namely the "filters", we developed a GUI. The GUI also provides the only interface, of our group at this time, capable of manipulating the full functionality involved with "filters".

Object transport grammar

We specified a grammar for serializing Directory Service information for storage and transport purposes. This grammar, defined in detail in section six of this report, has retained the property of being composed entirely of human readable ASCII text. Before any work on developing the server application and client API, the grammar was solidified based on the information available to us at the time. The following notions influenced the development of the grammar.

Should be human readable and understandable at a quick glance for easy debugging. This was accomplished by sticking to using only alpha-numerics to hold data and delimiters of a limited set of easy-to-read ASCII and common control characters.
Characters such as "@",".",":","'" cannot be used due to their possible occurrence within user data fields. (ie: email addresses, IP address fields, and conference names)
The concept of applying meta tags to the address fields was proposed to clearly present the data type of a field in which multiple data types can exist.

Server

We implemented our server in C++ on Solaris 2.6. Transactions with the server are characterized by a one-line request followed by a one-line response using TCP. The server parses commands, performs user authentication and policy checks, and ultimately performs the required database operation. The server uses gdbm as its database backend. For simplicity of database locking, the server runs in a single process and is not multithreaded.

Security

All transactions with the directory server require valid user authentication. Account management commands require administrative credentials, and user-level commands require either administrative or user credentials.

Filters

Flexibility was of a high priority. The grammar allows for multiple "filters", to be specified per registered user account. Each "filter" allows for multiple addresses to be defined, for a specified period of time. In effect this allows a user to divide his or her day into any amount of time slices, and for each slice specify a list of information regarding where and how to be reached. Here is an example for a user who wishes to be contacted either at their work machine or work phone (607-254-1010) number between the hours of 9am and 5pm (EST). The user would like to be contacted at their home phone (607-256-1234) or home computer (on dialup) between 6am to 9am, and again at 5pm to 10pm. After 10pm and before 6am they would like all contacts to be redirected to an answering machine (607-256-1235). Recall that filters are specified in GMT.

filter 1 : "0400:1200 pots!6072541010,ip!officemachine.atwork.com:1234"
filter 2 : "0100:0359 pots!6072561234,roam!"
filter 3 : "1201:1700 pots!6072561234,roam!"
filter 4 : "default pots!6072561235"

Meta-tags

Tag	Description	Example
ip	An ip address or FQDN plus a port number.	ip!127.0.0.1:1234 , ip!foo.bar.org:31415
pots	A telephone number.	pots!2540001
roam	Expands to the user's current roaming address, if the roaming address is defined and not expired.	roam!
user	Specifies the owner of a conference.	user!joe

Multiparty conference support

Conference support has been implemented for both public and private access conferencing. A conference is stored in the directory service database as a user account that has an owner. If the account's password field is empty the conference is publically accessible, otherwise in order to perform the lookup on the conference a password is required. Conferences make use of the "user!" meta-tag in their filter list to specify which user to be contacted when joining a conference. Creating and managing conferences requires only user credentials.

Browsing support In order to support users who are seeking parties or conferences to call, the directory service provides functions for listing all parties and conferences in the database.