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.
SHORT DESCRIPTION:
This assignment is exactly the same as the first one except it uses
RPC or RMI, the rest is the same.
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
RPC
or Java RMI, 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.
CLIENT:
The client should accept a hostname (where server is running) 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.
The following is a sample sequence of events that should happen:
1. Start the LDAP server : e.g.
hostA %LDAPserver & "NOTE:
You may or may not need & to run the server in background"
hostA %
2. Run the client to talk to the server: e.g.
hostB % LDAPclient hostA
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