Quick Response (QR) codes are two-dimensional codes designed to be read by smartphones. They consist of a black module arranged in a square pattern on a white background. While QR codes can encode many kinds of information, a common use is to encode URLs, such as to advertise the web address of a restaurant in a hard copy magazine. Using QR codes save mistakes in copying URLs from hard copy sources because a smartphone user can simply take a picture of the QR code and let an application on the phone convert the picture to a URL. Subsequently, the web page corresponding to that URL can be fetched.
The conversion of a QR code into the corresponding URL is currently done locally at a mobile device and the corresponding web page fetched after the conversion. A battery saving alternative would be to let a remote QR code server, say hosted on a commercial cloud service, carry out the conversion and then request the web page on behalf of the smartphone user. The smartphone then only has to display the web page to the user.
In this project, you will create such a QR code server for public use. You will also create a simple client application that fetches web pages using the QR code server. The goal of this project is not only to familiarize you with QR codes but also to help you learn and practice sockets programming.
Your server should run on the CS Linux machines on a specified port. The operator of this server would invoke it as: "./QRcodeServer [option1, ..., optionN]". The possible options are (if a particular option is not specified, its default value should be used):
Details of each option are given below:
Administrative log: The administrative log reports user activity and system behavior for the server operator. All entries should be prefixed with the time and client IP address in MM/DD/YY HH:MM:SS xxx.xxx.xxx.xxx format, where "MM/DD/YY" is the date and "HH:MM:SS" is the timestamp in international format (HH can take values from 0-23). Invalid commands from clients should be logged. The log file must also contain information about server startups, connections and disconnections from users, events as described by the RATE/MAX_USERS instructions, and any other information regarding user behavior or system events.
Clients should connect to the QR code server using TCP. The server should provide separate and concurrent sessions for each client. This can be accomplished using a new process for each user (via fork) or via threads. Each connected user should be able to run the following commands:
Expectations on concurrency: We require that each connecting client has a seperate thread or process spawned to handle its interactions. No possible execution paths of these concurrent threads or processes should lead to an error. Specifically, ensure that you protect all functions and library calls explicitly unless they are noted to be thread safe. As an example, when updating the administrative log file, make sure that events corresponding to multiple clients are recorded correctly. All memory should be freed when your server program exits. Specificaly, there should not be any memory leaks or zombie threads or processes. Do not rely on the OS to clean up terminated threads or processes.
The QR code server for P538 students is expected to send a complete HTTP header in its GET request for a URL. Specifically, they should provide the following fields in their GET request: Accept, Accept-Language, Host, User-Agent, Connection, Accept-Encoding.
P538 server should also parse the resulting HTTP header from the remote server in order to derive caching information. Using that information, P538 students will implement a simple caching system. In essence, unless the response is marked as not cacheable, it should be stored locally by the server. Any future requests against that URL should then be served from the cache, unless the cached element is stale. Care must be taken to ensure concurrency while implementing caching.
You are required to use either C or C++ for this assignment. Additionally, you must use the native Linux/BSD socket system calls. You may not use other socket libraries. No credit will be given to solutions that do not adhere to these requirements. These restrictions are being made so you become familiar with the details of lower-level socket programming.
ZXing is a library for generating and decoding QR codes.
Ordinarily, you would include the header files and make function calls to it.
However, it requires dependencies that are not available on all the CS linux
machines. As such, we will supply a pair of jar
files that can be used to run a decoder. Specifically, you can run the
decoder by:
java -cp javase.jar:core.jar
com.google.zxing.client.j2se.CommandLineRunner [image_file]
You can test this using this sample QR code
As always, you are encouraged to avail yourself to Internet resources and Linux manual pages when completing the assignment. Socket tutorials such as, http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html will be helpful in understanding socket programming. However, you must ensure that you write your own code and explicitly mention any resources you use, including web tutorials and discussions with individuals outside of your group. In case of any questions about making use of a specific web resource for the project, seek clarification via the class webboard.
The following system calls will likely be required to complete the assignment: listen, accept, bind, recv, send, setsockopt, socket, close, gethostbyname, getprotobyname, htons, ntohs, fork, exec, dup2, waitpid, system. Before getting started, you should consult the manual pages for each of these system calls. Additionally, you would need functions to perform thread or process synchronization.
Build your program incrementally. Here is a road-map to use:
Submit your code, and project files as a single archive file (.tar or .tar.gz file formats only) via OnCourse. Shorly after the submission deadline, demo slots will be posted on the Demonstration Scheduling System (a reminder will be posted on the Web Board). You must schedule an appointment to demonstrate your project. Groups that fail to demonstrate their project will not receive credit for the project. If a group member fails to attend his or her scheduled demonstration time slot, it will result in a 10 point reduction in his or her grade.
In addition to testing your code for various test cases, the AIs will be explicitly evaluating the contributions of individual project partners. In cases where they determine that partners have not contributed equally, differential grading will be used. The instructor and the AIs reserve the right to determine appropriate penalty in such cases.
