number>
If we could find this user ID in the
graph, the Main Server will
receive the searching results from
serverA/B and send them to
client1/2
The Main server has received searching result(s) of User
The Main Server has sent searching result(s) to client
using TCP over port
If we could not find this user ID
in the graph, send the error
message back to client
The Main server has received “User ID: Not found” from
The Main Server has sent error to client using TCP over
Table 7. Client 1 on-screen messages
Event On-screen Messages
Booting up(only while starting) Client1 is up and running
Please enter the User ID:
Please enter the Country Name:
After sending User ID to Main
Server:
Client1 has sent User and to
Main Server using TCP
If input country not found not found
If input User ID not found User not found
If input User ID and country can
be found:
Client1 has received results from Main Server:
User, User is/are possible friend(s)
of User in
Table 8. Client 2 on-screen messages
Event On-screen Messages
Booting up(only while starting) The client is up and running
Please enter the User ID:
Please enter the Country Name:
After sending User ID to Main
Server:
Client2 has sent User and to
Main Server using TCP
If input country not found not found
If input User ID not found User not found
If input User ID and country can
be found:
Client2 has received results from Main Server:
User, User is/are possible friend(s)
of User in
ASSUMPTIONS
1. You have to start the processes in this order: Backend-server (A), Backend-server (B),
Main-server, and Client 1, Client 2.
2. The data1.txt and data2.txt files are created before your program starts.
3. If you need to have more code files than the ones that are mentioned here, please use
meaningful names and all small letters and mention them all in your README file.
4. You are allowed to use code snippets from Beej’s socket programming tutorial (Beej’s
guide to network programming) in your project. However, you need to mark the copied part
in your code.
5. When you run your code, if you get the message “port already in use” or “address already
in use”, please first check to see if you have a zombie process (see following). If you do
not have such zombie processes or if you still get this message after terminating all zombie
processes, try changing the static UDP or TCP port number corresponding to this error
message (all port numbers below 1024 are reserved and must not be used). If you have to
change the port number, please do mention it in your README file and provide reasons for
it.
6. You may create zombie processes while testing your codes, please make sure you kill
them every time you want to run your code. To see a list of all zombie processes, try this
command:
ps -aux | grep developer
Identify the zombie processes and their process number and kill them by typing at the
command-line:
REQUIREMENTS
1. Do not hardcode the TCP or UDP port numbers that are to be obtained dynamically.
Refer to Table 3 to see which ports are statically defined and which ones are dynamically
assigned. Use getsockname() function to retrieve the locally-bound port number wherever
ports are assigned dynamically as shown below:
/*Retrieve the locally-bound name of the specified socket and store it in the sockaddr structure*/ getsock_check=getsockname(TCP_Connect_Sock,(struct sockaddr *)&my_addr, (socklen_t *)&addrlen); //Error checking if (getsock_check== -1) { perror("getsockname"); exit(1); }
2. The host name must be hard-coded as localhost (127.0.0.1) in all codes.
3. Your client should keep running and ask to enter a new request after displaying the
previous result, until the TAs manually terminate it by Ctrl+C. The backend servers and the
Main server should keep running and be waiting for another request until the TAs terminate
them by Ctrl+C. If they terminate before that, you will lose some points for it.
4. All the naming conventions and the on-screen messages must conform to the previously
mentioned rules.
5. You are not allowed to pass any parameter or value or string or character as a
command-line argument.
6. All the on-screen messages must conform exactly to the project description. You should
not add anymore on-screen messages. If you need to do so for the debugging purposes, you
must comment out all of the extra messages before you submit your project.
7. Please use fork() or similar system calls to create concurrent processes is not mandatory
if you do not feel comfortable using them. However, the use of fork() for the creation of a
child process when a new TCP connection is accepted is mandatory and everyone should
support it. This is useful when different clients are trying to connect to the same server
simultaneously. If you don’t use fork() in the Main server when a new connection is
accepted, the Main Server won’t be able to handle the concurrent connections.
8. Please do remember to close the socket and tear down the connection once you are done
using that socket.
Programming Platform and Environment
1. All your submitted code MUST work well on the provided virtual machine Ubuntu.
2. All submissions will only be graded on the provided Ubuntu. TAs won’t make any
updates or changes to the virtual machine. It’s your responsibility to make sure your code
works well on the provided Ubuntu. “It works well on my machine” is not an excuse and we
don’t care.
3. Your submission MUST have a Makefile. Please follow the requirements in the
following “Submission Rules” section.
Programming Languages and Compilers
You must use only C/C++ on UNIX as well as UNIX Socket programming commands and
functions. Here are the pointers for Beej's Guide to C Programming and Network Programming
(socket programming):
http://www.beej.us/guide/bgnet/
(If you are new to socket programming please do study this tutorial carefully as soon as possible
and before starting the project)
http://www.beej.us/guide/bgc/
You can use a Unix text editor like emacs or gedit to type your code and then use compilers such
as g++ (for C++) and gcc (for C) that are already installed on Ubuntu to compile your code. You
must use the following commands and switches to compile yourfile.c or yourfile.cpp. It will
make an executable by the name of "yourfileoutput”.
gcc -o yourfileoutput yourfile.c
g++ -o yourfileoutput yourfile.cpp
Do NOT forget the mandatory naming conventions mentioned before!
Also inside your code you may need to include these header files in addition to any other header
file you used:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
Submission Rules
Along with your code files, include a README file and a Makefile. In the README file
write:
● Your Full Name as given in the class list
● Your Student ID
● What you have done in the assignment.
● What your code files are and what each one of them does. (Please do not repeat the
project description, just name your code files and briefly mention what they do).
● The format of all the messages exchanged.
● Any idiosyncrasy of your project. It should say under what conditions the project
fails, if any.
● Reused Code: Did you use code from anywhere for your project? If not, say so. If
so, say what functions and where they're from. (Also identify this with a comment in
the source code.)
SUBMISSIONS WITHOUT README AND MAKEFILE WILL BE SUBJECT TO A
SERIOUS PENALTY.
About the Makefile
Makefile Tutorial:
https://www.cs.swarthmore.edu/~newhall/unixhelp/howto_makefiles.html
Makefile should support following functions:
Compile all your files and creates executables make all
Run server A make serverA
Run server B make serverB
Run Main Server make mainserver
Run client 1 ./client
Run client 2 ./client
TAs will first compile all codes using make all. They will then open 5 different terminal
windows. On 3 terminals they will start servers A, B and Main Server using commands make
serverA, make serverB, and make mainserver. Remember that servers should always be on
once started. On the 5th terminal they will start the client as “./client". TAs will check the
outputs for multiple queries. The terminals should display the messages specified above.
1. Compress all your files including the README file into a single “tar ball” and call it:
ee450_yourUSCusername_session#.tar.gz (all small letters) e.g. my filename would be
ee450_nanantha_session1.tar.gz. Please make sure that your name matches the one in
the class list. Here are the instructions:
On your VM, go to the directory which has all your project files. Remove all executable
and other unnecessary files. Only include the required source code files, Makefile and
the README file. Now run the following commands:
tar cvf ee450_yourUSCusername_session#.tar *
gzip ee450_yourUSCusername_session#.tar
Now, you will find a file named “ee450_yourUSCusername_session#.tar.gz” in the same
directory. Please notice there is a star (*) at the end of the first command.
2. Do NOT include anything not required in your tar.gz file. Do NOT use subfolders. Any
compressed format other than .tar.gz will NOT be graded!
3. Upload “ee450_yourUSCusername_session#.tar.gz” to the Digital Dropbox on the DEN
website (DEN -> EE450 -> My Tools -> Assignments -> Socket Project). After the file is
uploaded to the drop box, you must click on the “send” button to actually submit it. If
you do not click on “send”, the file will not be submitted.
4. D2L will keep a history of all your submissions. If you make multiple submissions, we
will grade your latest valid submission. Submission after the deadline is considered as
invalid.
5. D2L will send you a “Dropbox submission receipt” to confirm your submission. So
please do check your emails to make sure your submission is successfully received. If
you don’t receive a confirmation email, try again later and contact your TA if it always
fails.
6. Please take into account all kinds of possible technical issues and do expect a huge traffic
on the DEN website very close to the deadline which may render your submission or
even access to DEN unsuccessful.
7. Please DO NOT wait till the last 5 minutes to upload and submit because some technical
issues might happen and you will miss the deadline. And a kind suggestion, if you still
get some bugs one hour before the deadline, please make a submission first to make sure
you will get some points for your hard work!
8. After receiving the confirmation email, please confirm your submission by downloading
and compiling it on your machine. If the outcome is not what you expected, try to
resubmit and confirm again. We will only grade what you submitted even though it’s
corrupted.
9. You have plenty of time to work on this project and submit it in time hence there is
absolutely zero tolerance for late submissions! Do NOT assume that there will be a late
submission penalty or a grace period. If you submit your project late (no matter for what
reason or excuse or even technical issues), you simply receive a zero for the project.
GRADING CRITERIA
Notice: We will only grade what is already done by the program instead of what will be
done.
For example, the TCP connection is established and data is sent to the Main Server. But the
result is not received by the client because Main-server got some errors. Then you will lose some
points for phase 1 even though it might work well.
Your project grade will depend on the following:
1. Correct functionality, i.e. how well your programs fulfill the requirements of the
assignment, especially the communications through UDP and TCP sockets.
2. Inline comments in your code. This is important as this will help in understanding what
you have done.
3. Whether your programs work as you say they would in the README file.
4. Whether your programs print out the appropriate error messages and results.
5. If your submitted codes do not even compile, you will receive 5 out of 100 for the
project.
6. If your submitted codes compile using make but when executed, produce runtime errors
without performing any tasks of the project, you will receive 10 out of 100.
7. If you forget to include the README file or Makefile in the project tar-ball that you
submitted, you will lose 15 points for each missing file (plus you need to send the file to
the TA in order for your project to be graded.)
8. If you add subfolders or compress files in the wrong way, you will lose 2 points each.
9. If your code does not correctly assign the TCP or UDP port numbers (in any phase), you
will lose 10 points each.
10. You will lose 5 points for each error or a task that is not done correctly.
11. The minimum grade for an on-time submitted project is 10 out of 100, assuming there are
no compilation errors and the submission includes a working Makefile and a README.
12. There are no points for the effort or the time you spend working on the project or reading
the tutorial. If you spend about 2 months on this project and it doesn’t even compile, you
will receive only 5 out of 100.
13. You must discuss all project related issues on Piazza. We will give those who actively
help others out by answering questions on Piazza up to 10 bonus points. If you want to
earn the extra credits, do remember to leave your names visible to instructors when
answering questions on Piazza. Also, you will NOT get credit by repeating others’
answers.
14. The maximum points that you can receive for the project with the bonus points is 100. In
other words the bonus points will only improve your grade if your grade is less than 100.
15. Your code will not be altered in any way for grading purposes and however it will be
tested with different inputs. Your designated TA runs your project as is, according to the
project description and your README file and then checks whether it works correctly or
not. If your README is not consistent with the description, we will follow the
description.
FINAL WORDS
1. Start on this project early. Hard deadline is strictly enforced. No grace periods. No grace
days. No exceptions.
2. In view of what is a recurring complaint near the end of a project, we want to make it
clear that the target platform on which the project is supposed to run is the provided
Ubuntu (16.04). It is strongly recommended that students develop their code on this
virtual machine. In case students wish to develop their programs on their personal
machines, possibly running other operating systems, they are expected to deal with
technical and incompatibility issues (on their own) to ensure that the final project
compiles and runs on the requested virtual machine. If you do development on your own
machine, please leave at least three days to make it work on Ubuntu. It might take much
longer than you expect because of some incompatibility issues.
3. Check Piazza regularly for additional requirements and latest updates about the project
guidelines. Any project changes announced on Piazza are final and overwrites the
respective description mentioned in this document.
4. Plagiarism will not be tolerated and will result in an “F” in the course.