TDC 561: Network Programming, Winter 07

TDC 561: Network Programming, Winter 08

Assignment 3: Maltreated and Multicasts Distributed Database System

Due: 5:45pm, 19 March 2008

Assignment Description

In this network programming assignment, you will develop a simple distributed database system similar to Assignment 1 and 2 but using multithreading instead of forking or I/O multiplexing, and multicast instead of unicast. The following is the deign specification of both the client msimddb and server msimddbd:

Multicast Distributed Database Client—msimddb: (40%)

The client msimddb using UDP to send a multicast request to the servers. The client as usual reads the configuration of the database servers from a file called ddbconfig.txt which is formatted as follows:

Example of ddbconfig.txt is as follows:

---------------------------------------------

224.4.4.4 4000 name ssn

224.5.5.5 5000 ssn course_code

224.6.6.6 6000 course_code location

--------------------------------------------------

Then the client connects to each database server in the config file. The client then reads from the STDIN the UQ, fragments it into CQ, and sends each one as a multicast message to each of the corresponding server groups. The message format for query, insert and delete is the same as in assignment 1 and 2.

Each server in the same will always use unicast UDP to send the reply or a confirmation/error message for each DB request. This means that the client could receive multiple responses for the same subquery from the server group. However, since the client does not know the order in which these responses will arrive, it must use select() to receive the first one and read and ignore the other ones. Since the DB request or the reply are sent using UDP, they could be lost!! The client should time out after 2 seconds and retransmit if the reply is not used. This could be handled by select() too. The format of the confirmation messages is the same as in assignment#1 and 2.

After the client multicast the CQ to the server group, it reads the responses construct the next CQ to be sent to the next group and so on as in assignment #1 and 2. The client will continuously reads user queries from the STDIN till the user hits <ctr><c> which will cause the client to exit.

Multithread and Multicast Concurrent Distributed Database Server—msimddbd: (50%)

The server msimddbd will first bind to a port and join a a multicast group that are both passed in the commands line argument as follows: $msimddbd <PortNumber> <MulticastGrp>. To avoid the port conflict with your classmates, you can use as a default value for Portnumber 1024 + the last four digits of your SSN. Then the servers in the same group read the db records from a file “<portnumber>.db” (e.g., 6000.db) and load it up in a array of structures as in assignment 1 and 2. Notice that you need to use reuse port socket option in order to run multiple server joining the same group on the same machine (hawk).

When the server receives a query, it will create a thread and hand it over to the thread works to process request and send back the response. Thus the server can read and process multiple requests simultaneously. This might cause race conditions and inconsistency in the DB. You need to provide mutual exclusion when accessing DB in order to synchronize the threads. The server will send back the response using unicast UDP. The main thread will only reads the request and creates the thread works. The thread works will process the request, send the reply and exit. Thus there is a thread per request.

Running Example:

$msimddbd 224.4.4.4 4000

$msimddbd 244.5.5.5 5000

$msimddbd 244.6.6.6 6000

$msimddb /* notice that the client get the port numbers to connect to from the config file */

UserQueyInterface>Q name=Jimmy, ssn?

1234 /* this is the response from the server(s) */

UserQueyInterface>Q name=Jimmy, course_code?

TDC561

UserQueyInterface>Q name=Jimmy, location?

Luis 1216

UserQueyInterface>Q course_code=TDC561, location?

Luis 1216

UserQueyInterface>I name=Ken, ssn= 4567?

UserQueyInterface>D name=Ehab?

Error: Name Not Found

<ctr><c>

HINT:

(1) Start with multithreading with TCP then replace TCP with unicast UDP then do it with multicast. Then fianllly add matual execultion.

(2) You will use the same message struct that were used in assignment#1 and 2. For example, this is how you create a message structure for Insert req:

Typedef ATTRIBUTE {

char name[32];

} Attribute;

struct INSERTQ {

int reqtype;

char key[32];

int numberofAtt;

Attribute ListofAttributes [10];

} IQ;

(5) To do the message encoding, packetization, reading and writing, refer to slides (PacketizationI.pdf) under Resources in the course home page.

Submission Procedure:

Write your name and SSN in the main program and in the README file. After cleaning your directory from objects and bin files, do the following: (Your submission must contain a Makefile and a README file that describes how to run your program). You must use the same naming convention and command line arguments as specified in the assignment description.

Delete any bin executables or object files, first.
$ tar -cvf <HawkLogin>-<SSNLast4>-hw3.tar *
$gzip <HawkLogin>-<SSNLast4>-hw3.tar
$ ftp as ”bin” to your local desktop (you just type bin in the ftp prompt)

(if you do not enable the “bin” option, your file will be corrupted)

Upload you it to DLWEB

For verification: upload it back from your DLWEB into your local unix directory and untar it to make sure that every things works fine.

NOTE: Students are responsible to upload a working copy in the right slot. Thus you may “download”, “untar” and then “compile” it to verify that it works. DO NOT for get to exclude any binary or object files in your submission

Grading Policy (READ THIS CARFULLY):

Late penalty is 10% per day. 30 % for the server program, 20% concurrency, 30% for the clients, 10% for cleaning up and 10% for the README and Makefile files. Use the same naming conventions and command line argument as described above.

If you have a question about the homework, then the best thing is to ask during office hours or in class. DO NOT wait until few days before the deadline to start on the assignment. The assignments are designed to almost fit the given time window.

The grader should explain clearly the reason for the deduction if any. Read the comment and in case of questions or dispute then follow this process:

(1) Send email to the grader requesting re-grading your assignment,

(2) If they grader did not reply back or his reply was not sufficient, then send an email to the instructor at the word-reverse of this string (edu.depaul.cs@ehabclass) or better to meet him during office hours. The grader name and email will be announced in class.

We will discuss briefly Makefile in class. But I expect students to handle the Makefile and C language issues individually. But if you look under Resources link in the course home page, you will find tutorials and enough information to get you started in Makefile and Unix. This course is very fun.. the average is normally is very high and the experience is highly appreciated. Good Luck.