Home Page > > Details

EE450 Programming CourseHelp With , C/C++ Programming,Programming ProgrammingHelp With Web| Haskell Programming

EE450 Socket Programming Project
Fall 2020
Due Date:
Thursday, November 5, 2020 11:59PM
(Hard Deadline, Strictly Enforced)
The deadline is for both on-campus and DEN off-campus students.
OBJECTIVE
The objective of this assignment is to familiarize you with UNIX socket programming. This
assignment is worth 15% of your overall grade in this course. It is an individual assignment
and no collaborations are allowed. Any cheating will result in an automatic F in the course
(not just in the assignment).
If you have any doubts/questions, post your questions on Piazza. 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 to the project.
You can ask TAs any question about the content of the project but TAs have the right to
reject your request for debugging.
PROBLEM STATEMENT
Nowadays, social recommendation is an important task to enable online users to discover friends
to follow, pages to read and items to buy. Big companies such as Facebook and Amazon heavily
rely on high-quality recommendations to keep their users active. There exist numerous
recommendation algorithms --- from the simple one based on common neighbor counting, to
more complicated one based on deep learning models such as Graph Neural Networks. The
common setup for those algorithms is that they represent the social network as a graph, and
perform various operations on the nodes and edges.
In this project, you will implement a simple application to generate customized
recommendations based on user queries. Specifically, consider that Facebook users in different
countries want to follow new friends. They would send their queries to a Facebook server (i.e.,
main server) and receive the new friend suggestions as the reply from the same main server.
Now since the Facebook social network is so large that it is impossible to store all the user
information in a single machine. So we consider a distributed system design where the main
server is further connected to many (in our case, two) backend servers. Each backend server
stores the Facebook social network for different countries. For example, backend server A may
store the user data of Canada and the US, and backend server B may store the data of Europe.
Therefore, once the main server receives a user query, it decodes the query and further sends a
request to the corresponding backend server. The backend server will search through its local
data, identify the new friend to be recommended and reply to the main server. Finally, the main
server will reply to the user to conclude the process.
The detailed operations to be performed by all the parties are described with the help of Figure 1.
There are in total 5 communication end-points:
● Client 1 and Client 2: representing two different users, possibly in different countries
● Main server: responsible for interacting with the clients and the backend servers
● Backend server A and Backend server B: responsible for generating the new friend based
on the query
○ For simplicity, user data is stored as plain text. Backend server A stores data1.txt
and Backend server B stores data2.txt in their local file system.
The full process can be roughly divided into four phases (see also “DETAILED
EXPLANATION” section), the communication and computation steps are as follows:
Bootup
1. [Computation]: Backend server A and B read the files data1.txt and data2.txt
respectively, and construct a list of “graphs” (see “DETAILED EXPLANATION” for
description of suggested data structures for graphs).
○ Assume a “static” social network where contents in data1.txt and data2.txt do not
change throughout the entire process.
○ Backend servers only need to read the text files once. When Backend servers are
handling user queries, they will refer to the internally represented graphs, not the
text files.
○ For simplicity, there is no overlap of countries between data1.txt and data2.txt.
2. [Communication]: after step 1, Main server will ask each of Backend servers which
countries they are responsible for.
3. [Computation]: Main server will construct a data structure to book-keep such information
from step 2. When the client queries come, the main server can send a request to the
correct Backend server.
Query
1. [Communication]: Clients send their queries to the Main server.
○ A client can terminate itself only after it receives a reply from the server (in the
Reply phase).
○ Main server may be connected to both clients at the same time.
2. [Computation]: Once the Main server receives the queries, it decodes the queries and
decides which backend server(s) should handle the queries.
Recommendation
1. [Communication] Main server sends a message to the corresponding backend server so
that the Backend server can perform local computation to generate recommendations.
2. [Computation]: Backend server performs some operations on the graph for friend
recommendations, which is based on the number of common neighbors. You need to
implement the algorithm on Backend servers to count the number of common neighbors.
3. [Communication]: Backend servers, after generating the recommendations, will reply to
Main server.
Reply
1. [Computation]: Main server decodes the messages from Backend servers and then
decides which recommendations correspond to which client queries.
2. [Communication]: Main server prepares a reply message and sends it to the appropriate
Client.
3. [Communication]: Clients receive the recommendation from Main server and display it.
Clients should keep active for further inputted queries, until the program is manually
killed.
The format of data1.txt or data2.txt is defined as follows.

of user 1>
of user 2>
...

...
Let’s consider an example:
Let’s say there are three countries, “A”, “Canada” and “xYz”. In country A, there are three users
with ID 0, 1 and 2. In country Canada, there are five users with IDs 78, 2, 8, 3 and 11. In country
xYz, there are three users with IDs 1, 0 and 3. Although both country A and country xYz have
the same user ID 0 and 1, they are not the same user (See Assumption 7 below).
Assume data1.txt stores the user data for countries A and xYz, and data2.txt stores the user data
for country Canada.
Example data1.txt:
A
0 1 2
1 2 0
2 1 0
xYz
1 0 3
0 1
3 1
Example data2.txt:
Canada
3 8
2 8
11
8 78 2 3
78 8
Assumptions on the data file:
1. We consider undirected connections between any pair of users. For example, if there is a
connection from user 1 to user 0, then there must be a connection from user 0 to user 1.
2. There may be isolated users. That is, a user may not have any connection to other users
(e.g., user 11 in country Canada).
3. Each user will have one line in the text file. Even though 11 in Canada has no other
connections, there is still a line for 11 in data2.txt.
4. Country names are in letters. The length of the name can vary from 1 letter to at most 20
letters. There can be both capital and lowercase letters in the name. Country name does
not contain any white spaces.
5. User IDs are represented by non-negative integer numbers.
6. Within the same country, user IDs do not need to be consecutive. I.e., if a country
contains N users, their IDs do not need to be 0, 1, 2, …, N-1. See the case of Canada and
xYz.
7. The pair (country name, user ID) uniquely identifies a user around the world.
○ Users in different countries may have the same ID.
○ Users in the same country do not have the same ID.
8. User ID may not start from 0. See the case of Canada.
9. The maximum possible user ID is (2^31 - 1). The minimum possible user ID is 0.
○ This ensures that you can always use int32 to store the user ID.
○ Backend servers may also want to re-index the user IDs when constructing the
graph.
10. There are at most 10 countries in total.
11. There is no additional empty line(s) at the beginning or the end of the file. That is, the
whole data1.txt and data2.txt do not contain any empty lines.
12. For simplicity, there is no overlap of countries between data1.txt and data2.txt.
13. The user IDs in data1.txt and data2.txt are separated by white space(s). That is, there will
be at least one white space between two IDs, but there can also be multiple spaces.
14. A user will not connect to him/herself.
15. For a given user, his/her corresponding line in the text file may contain repeated neighbor
ID.
○ For example, it is still a valid file if we replace the second line of data1.txt with
“0 1 2 1”
16. The user IDs in the text are not sorted.
17. data1.txt and data2.txt will not be empty.
18. A country will have at least one user, and at most 100 users.
A sample data1.txt and data2.txt is provided for you as a reference. Please refer to the
“DOWNLOAD SAMPLES” Section to download them. Other data1.txt and data2.txt will be
used for grading, so you are advised to prepare your own files for testing purposes.
Source Code Files
Your implementation should include the source code files described below, for each component
of the system.
1. servermain: You must name your code file: servermain.c or servermain.cc or
servermain.cpp (all small letters). Also you must name the corresponding header file (if you
have one; it is not mandatory) servermain.h (all small letters).
2. Backend-Server A and B: You must use one of these names for this piece of code:
server#.c or server#.cc or server#.cpp (all small letters except for #). Also you must name
the corresponding header file (if you have one; it is not mandatory) server#.h (all small
letters, except for #). The “#” character must be replaced by the server identifier (i.e. A or B),
e.g., serverA.c.
3. Client: The name for this piece of code must be client.c or client.cc or client.cpp (all
small letters) and the header file (if you have one; it is not mandatory) must be called client.h
(all small letters).
Note: Your compilation should generate separate executable files for each of the components
listed above.
DETAILED EXPLANATION
Phase 1 (10 points) -- Bootup
All three server programs (Main server, Backend servers A & B) boot up in this phase. While
booting up, the servers must display a boot up message on the terminal. The format of the boot
up message for each server is given in the onscreen message tables at the end of the document.
As the boot up message indicates, each server must listen on the appropriate port for incoming
packets/connections.
As described in the previous section, the backend server needs to read the text file and convert
the social network into graphs --- one graph per country. There are many ways to represent a
graph. For example, adjacency matrix, adjacency list or Compressed Sparse Row (CSR) format.
You need to decide which format to use based on the requirement of the problem. You can use
any format as long as you can generate the correct recommendation.
For example, suppose Backend serve 2 re-indexed the Canada users as
Original user ID Re-indexed user ID
3 0
2 1
11 2
8 3
78 4
Then the adjacency matrix for the graph will be:
Where the element at the i-th row and j-th column will be 1 if there is a connection between the
(re-indexed) user i and user j.
Again, you are welcome to use other ways to represent the graph. Once Backend server finishes
processing the files of data1.txt and data2.txt, Main server will ask Backend servers so that Main
server knows which Backend server is responsible for which countries. The communication
between Main server and Backend servers is using UDP. For example, Main server may use an
unordered_map to store the following information:
std::unordered_map

Contact Us - Email:99515681@qq.com    WeChat:codinghelp
Programming Assignment Help!