Lab 2: Design A Standardized Client-Server Application Solution

Description

Your lab must meet two key requirements:

1) your client must interoperate/work with any (working) server of other classmates, and

2) your server must interoperate/work with any (working) client of other classmates.

Languages: you must use C/C++ for the server AND any other language of your choice for the client. Your code must ultimately compile and execute on Unix Tux engineering machines. The TA does not have to install any new tools to evaluate your code.

Datagram socket programming

The objective is to design a proxy DNS server over UDP. The client sends a list of Internet hostnames, the server will send back the list of IP addresses corresponding to the hostnames. We assume that the Internet may corrupt datagrams. Each group must design and implement one server and one client over UDP:

1. 1. Client : Write a datagram client (UDPClient.X ) in any language of your choice as long as it is ALREADY available on Tux machines. The Client must

      1. accept a command line of the form: UDPClient Servername Port# requestID n1 n2 ..nm where

         1. UDPClient is your executable,

         2. Servername is the server name,

         3. port# is a port number,

         4. RequestID is a request ID from 0 to 127, and

         5. n_i is a host name.

      2. form a message/datagram msg[] that contains the request ID RequestID and the list of hostnames n_i following the protocol described below.

      3. send the message msg[] as a UDP datagram containing the formed message to the server with Name Servername and Port Number Port# and wait for a response

      4. If the client receives a VALID response, it prints it out the response: one hostname and its IP address per line.

      5. If the client receives a corrupted/invalid response or a response too short then it must drop it and jumps to iii (Limit the number of trials to 7). An invalid response does not have the magic preamble (see later)

PROTOCOL: The message msg[] will contain the magic number 0x4A6F7921¹ (4 bytes), a total message length field (2 bytes) (TML), a checksum field (one byte), your group ID GID (one byte), a request ID (one byte), and a list of hostnames (H) formatted as follows: each hostname will be preceded by one byte that contains its length followed by the hostname. The format of the message msg[] : (L. stands for Length and H. stands Hostname)

0x4A6F7921	TML	GID	Checksum	Request ID	L. 1	H. 1	….	L.H n	H. n
4 bytes	2 bytes	1 byte	1 byte	1 byte	1 byte	variable	….	1 byte	variable

1. Magic Number: the magic number is always 0x4A6F7921 that announces a valid request. This field takes 4 bytes and is stored in msg[0], msg[1], msg[2], msg[3] in the network byte order.

2. Total Message Length: Length is stored on two bytes (msg[4], msg[5]). Length is the number of bytes making the packet (including the full header). TML must be sent in the network byte order.

3. Group ID GID: this byte msg[6] will contain the group ID who designed and implemented the client (your GID I hope!).

4. Checksum: Checksum is stored on Byte (msg[7]). Checksum is computed as follows: consider the message an array of bytes. The checksum must be computed as an 8 bit Internet checksum. The 16 bit Internet checksum is described on Page 212 (textbook). Let me know if you have a problem computing the checksum. See exercise page 253, # 15. Let S be the ONE BYTE current sum. Whenever S+msg[i] produces a carry, add it to S before adding the next number. Finally, Checksum is the bitwise one complement of S.

5. Request ID: this byte msg[8] will contain a number that identifies the request.

6. L.i : L.i is the length (the number of characters) of the hostname H.i.

7. H.i: H.i is the hostname.

IT IS CRITICAL that all groups compute correctly (and the same way) the checksum. Otherwise, a receiver from a different group will reject your messages.

Now…the Server

1. 2. Server: Write a datagram DNS-Proxy server (UDPServer.XXX) running on port (10010+GID). Use C or C++ to implement the server. The server must accept a command line of the form: UDPServer Port# where:

      1. UDPServer is your executable

      2. Port# is a port number. While testing your code, Port# must be set to 10010+GID.

      3. When the server receives a request, it checks whether the request is VALID. A request is INVALID if it does not have a magic number, is too short, or has a bad checksum. If the request is valid then the server must resolve the IP addresses and return a message with the header (magic number, the total length of the message, the checksum, the group ID GID, and the RequestID) followed by the IP addresses of all the hostnames requested.

0x4A6F7921	TML	GID	Checksum	Request ID	IP address 1	IP address 2	..	IP Address n
4 bytes	2 bytes	1 byte	1 byte	1 byte	4 bytes	4 bytes		4 bytes

Each IP address must be in the network byte order. The order of the IP addresses must the same as the order of the hostnames on the request. Note that the checksum is not the checksum received from the client. It is a checksum computed on the response datagram sent by the server.

If the request is invalid, the server must return a message with the header (magic number, the total length of the message, Checksum, GID) followed by one byte error code BEC.

0x4A6F7921	TML	GID	Checksum	Byte Error Code (BEC)
4 bytes	2 bytes	1 byte	1 byte	1 byte

If the request is too short/long (length mismatch), the least significant bit b₀ must be set to 1. If the checksum is bad, the bit b₁ must be set to 1. If the request does not have a magic number, the bit b₂ must be set to 1.

A message is VALID if it has the magic number, a good checksum and a correct length. The checksum is correct if the sum (computed the same as when computing the checksum) of ALL bytes composing the message (including the checksum) add up to -1 (0xff).

What to turn in?

1. Electronic copy of your report (standalone) and source code (zipped) of your programs. All programming files (source code) must be put in a zipped folder named lab1-name1-name2 where name1 and name2 are the last names of two teammates. Zip the folder and post it on Canvas. Submit separately (not inside the zipped folder) the report as a Microsoft or PDF file. A penalty of 10 points will be applied if these instructions are not followed.

2. Your report must:

   1. state whether your code works

   2. Clearly explain how to compile and execute your code. If the TA needs your presence to compile and execute your code, then a 30% penalty will be applied.

   3. If needed, report/analyze (as appropriate) the results. The quality of analysis and writing is critical to your grade.

Good writing and presentation are expected.

If the TA is unable to access/compile/execute your work based on your report, a 30% penalty will be applied.

If the turn in instructions are not correctly followed, 10 pts will be deducted.

Grading:

1) 50 points per program (One client and one server)

2) Code does not compile on a Tux machine: 0% credit

3) Code compiles on Tux machines but does not work: 5% credit

4) Code compiles and interacts correctly with counterpart from the same group: 70% credit

5) Code compiles and interacts correctly with counterpart from other groups: 100% credit

Advice to complete these exercises:

This is just an introduction to socket programming: I advise you to work ACTIVELY to implement these programs.

“How to get started?”:

I repeat: This is just an introduction to socket programming. I advise you to work ACTIVELY to implement these programs.

Step 1: download, compile, and execute Beej’s sample programs (UDP-client.c and UDP-server.c )

Step 2: get familiar with this code: study key socket programming calls/methods/functions

Step 3: improve the server to echo (send back) the string it received.

Step 4: improve the client to receive the echo and print it out.

Step 5: SAVE the improved versions (you may need to roll back to them when things will go bad)

Step 6: All you need now is “forming” your messages based on the specified format (lab 1 protocol).

Help Tools:

Besides this lab, I posted the following programs:

1. UPD-server.c (Beej’s datagram server)

2. UDP-client.c (Beej’s datagram client)

3. UDPServerDisplay.c : this program is a modification of Beej’s UDP server: it takes as input a port number to run on and displays in hexadecimal what it receives.

7) packedStruct.c : this program demoes how to create a “packed” struct.