Client/Server Computing (CIS604)

Programming Assignment #1

Last revision: 02-20-01

Date Posted: Tuesday, February 20, 2001
Date Due: Sunday, March 4, 2001  before 11:59 P.M.

Please submit your code ONLY by using my upload utility, onto "UPLOAD ASSIGNMENT 1" area.
FOLLOW THE NAMING CONVENTION.
PLEASE READ THE ENTIRE ASSIGNMENT (THIS PAGE) VERY CAREFULLY.
UPDATES TO THIS ASSIGNMENT WILL POSTED ON "MESSAGE OF THE DAY" PAGE.

BACKGROUND:
Lightweight Directory Access Protocol. LDAP is a directory service protocol that runs over TCP/IP. The
nitty-gritty details of LDAP are defined in RFD 1777 "The Lightweight Directory Access Protocol."
A directory is like a database, but tends to contain more descriptive, attribute-based information. The
information in a directory is generally read much more often than it is written. As a consequence, directories
don't usually implement the complicated transaction or roll-back schemes regular databases use for doing
high-volume complex updates. Directory updates are typically simple all-or-nothing changes, if they are allowed
at all. Directories are tuned to give quick-response to high-volume lookup or search operations. They may have
the ability to replicate information widely in order to increase availability and reliability, while reducing response
time. When directory information is replicated, temporary inconsistencies between the replicas may be OK, as
long as they get in sync eventually.

DESCRIPTION:
Write two programs in C, C++, perl or Java (other langs. with my written permission) to implement  an "LDAP" client and server system using sockets ONLY, for inter-process communication. We will not be implementing a complete LDAP server but just a watered-down version of it.

SERVER:
The server should run in the background of the system which it is invoked on. Upon startup of the server, a file called fname_lname.in (follow my naming convention for this file) in the current directory will be read. The contents of the file is the directory entry one line per record. The following is a sample format of the file:
login Name:first name:last name:day phone:eve phone:fax:e-mail adress:home address: etc...
You could add to the number of fields as much as you want.
Server should accept a port number to listen to, and awaits for client(s) to connect to it.

CLIENT:
The client should accept a hostname and port number to sent the request to. Client(s) will run in the foreground since they require user input.
Upon startup of the client, it will initiate a connections to the server then will give the user 4 menu items to choose from; 1-search for a record, 2-add a record, 3-delete a record, 4-quit. You may use more items if you want to.  At choice 1, user will type a word, for example "555" and the server should return EVERY entry containing the word "555." At choice 2, user will type a word, for example "555" and the server will delete EVERY entry containing the word "555." At choice 3, the server will ask all the necessary question to add the record, the minimum field to add an entry is the login name.
Port number on the client of course will be the same as that of the server, otherwise an error message will be generated stating so.
 

The following is a sample sequence of events that should happen:

1. Start the LDAP server : e.g.
    hostA %LDAPserver 1234 &
    hostA %

2. Run the client to talk to the server: e.g.
    hostB % LDAPclient  hostA 1234
    1- Search for a record
    2- Add a record
    3- Delete a record
    4- quit.
    Your choice: _1__
    Enter a keyword: Jim
    0 record(s) found.
OR
    6 record(s) found
 the records should be listed as
Login name:
First Name:
Last Name:
etc...

All error messages must be handled, and with a proper output starting with ERROR: error message.

GRADING CRITERIA:
Simply by writing a working or none working program your grade will not necessarily be an "A" or an "F" respectively, if that was the case everyone in the class would receive "A's" or "F's," of course that is not the case in any class (that I know) as well as this class. What is important to me is the clarity, modularity, scalability, ease of follow, enough comments, descriptive variable names, etc...
Of course if your program actually works, is better than if it does not work.

Please direct questions or errors to: CIS604@cis.njit.edu