程序代写 EE450 Socket Programming Project, Spring 2022 Due Date : Thursday April 24t

EE450 Socket Programming Project, Spring 2022 Due Date : Thursday April 24th, 2022 11:59
PM (Midnight)
(The deadline is the same for all on-campus and DEN off-campus students)
Hard Deadline (Strictly enforced)

Copyright By PowCoder代写 加微信 powcoder

The objective of this assignment is to familiarize you with UNIX socket programming. This assignment is worth 10% 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.
Problem Statement:
Digital transactions and cryptocurrencies have been a hot topic lately. People prefer to use digital transactions due to their simplicity and they choose cryptos because they provide a sense of safety and anonymity that regular currencies cannot. While the latter are not bounded by a government or a country, their success relies on the distributed nature of their platforms. The technology behind them is known as blockchain, a chain of information blocks where we store all the transactions that have taken place since the start of the system. The amount of transactions stored on a block depends on the type of blockchain and the information can be provided to every member of the system (public blockchain) or to a few members of it (permissioned blockchain) . In this project we shall implement a simplified version of a blockchain system that’ll help us understand how cryptocurrency transactions work. For this scenario, we will have three nodes on the blockchain where each stores a group of transactions. These will be represented by backend servers. While in the blockchain the transaction protocol deals with updating the digital wallet of each user, for this project we will have a main server in charge of running the calculations and updating the wallets for each user. Each transaction reported in the blockchain will include, in the following order, the transaction number, sender, receiver and amount being transferred.
In this project, you will implement a simplified version of a blockchain service called Alichain, where two clients issue a request for finding their current amount of alicoins in their account, transfer them to another client and provide a file statement with all the transactions in order. These requests will be sent to a Central Server which in turn interacts with three other backend servers for pulling information and data processing.

The Main server will connect to servers A, B and C, which have a group of transactions that are not in order. When required, the main server has to pull the transaction information from each backend server to find out the current wallet balance of the user, to transfer money from one user to another and to write back a file statement with all the transactions and store it on the Main server. The steps and explanation of each operation that will be required for the blockchain platform is provided in each phase of the project.
Figure 1. Illustration of the network
Server A has access to a file named block1.txt, server B has access to a file named block2.txt and server C has access to a file named block3.txt . Both clients and the main server communicate over a TCP connection while the communication between main server and the Back-Servers A, B & C is over a UDP connection. This setup is illustrated in Figure 1.
Source Code Files
Your implementation should include the source code files described below, for

each component of the system.
1. ServerM: You must name your code file: serverM.c or serverM.cc or serverM.cpp (all small letters except ‘M’). Also you must include the corresponding header file (if you have one; it is not mandatory) serverM.h (all small letters except ‘M’).
2. Back-Server A, B and C: 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 include 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 or C), depending on the server it corresponds to. Note: You are not allowed to use one executable for all four servers (i.e. a “fork” based implementation).
3. ClientA:ThenameofthispieceofcodemustbeclientA.corclientA.ccor clientA.cpp (all small letters) and the header file (if you have one; it is not mandatory) must be called clientA.h (all small letters).
4. ClientB:ThecodefileforthemonitormustbecalledclientB.corclientB.cc or clientB.cpp (all small letters) and the header file (if you have one; it is not mandatory) must be called clientB.h (all small letters).
Application workflow phase Description:
Phase 1: (30 points)
Establish the connections between the Clients and Main Server
All four server programs (Main Server, Backend ServerA, Backend ServerB and Backend ServerC) boot up in this phase. While booting up, the servers must display a boot message on the terminal. The format of the boot message for each server is given in the onscreen messages tables at the later part of the document. As the boot message indicates, each server must listen on the appropriate port information for incoming packets/connections.
Once the server programs have booted up, two client programs should run. Each client displays a boot message as indicated in the onscreen messages table. Note that each client code takes an input argument from the command line that specifies the username(s).
Note: Once started, the main server and the three backend servers should always be running (unless stopped manually). The clients can terminate their connections with the

main server once they receive the response for the operation they had requested (checking balance or performing a transaction) .
For the first two phases the client can perform two kinds of request operations, namely “CHECK WALLET”, “TXCOINS” (transfer coins). Which operation is performed depends on the number of input arguments that the code takes from the command line:
Operation1: CHECK WALLET
In this operation, the input argument should be the client’s own name and it will be used to fetch the client’s balance in the wallet, which will be described in the next section. The format for running each client code in this operation is:
The command for the client A should be ./clientA
The command for the client B should be ./clientB
The usernames from the ClientA and ClientB are the inputs for getting the balance of each of their wallets. As an example, to check client A’s wallet balance, the command should be run as follows:
./clientA Martin
Operation2: TXCOINS
In this operation, There will be three input arguments, namely the client name of the transfer out, the client name of the transfer in, and the number of transfers. The main server will complete and record this transaction according to the input arguments, more details will be described in the next section. The format for running each client code in this operation is:
The command for the client A should be
./clientA The command for the client B should be
./clientB

The usernames from the Clients are the inputs for transferring coins from one user to another. As an example, to transfer 100 alicoins from client A to client B should be run as follows
./clientA Martin Luke 100
After booting up, the ClientA and ClientB establish TCP connections with the server. After successfully establishing the connections, the two clients first send the usernames to Server C. Once these are sent, each client should print a message in the format given in the table 8 & 9. This ends Phase 1 and we now proceed to Phase 2.
Phase 2: (40 points)
Phase 2A: Main Server connects to backend servers and proceeds to retrieve the information.
In Phase 1, you read what should be sent from ClientA and ClientB to server M (main server) over the TCP connections. For Phase 2, Server M will send messages to the three back-servers (Server A, Server B and Server C) with UDP connections. The request will be sent to their respective back-end server depending on which information they need to get and which operation they need to execute.
Table 1: An example of the format for each Alichain transaction
Serial No.
Transfer Amount

Every member of the platform received 1000 alicoins as incentive to join this blockchain. On table 1 we can see the format of each row in the block files stored at the backend servers.
Operation1: CHECK WALLET
For this operation the main server will use the input username provided on phase 1 and check if the username is found on the transaction records while communicating with the backend servers. If the username is not found the main server will provide a message as indicated below on the On-screen messages portion of the document. If the username exists we will calculate the amount the username has on Alichain.
Operation2: TXCOINS
For this operation the main server will use the input username1 , username2 and amount provided on phase 1 and check if both usernames can be found on the records while communicating with the backend servers. If any of the usernames is not found the main server will provide a message as indicated below on the On-screen messages portion of the document. If both usernames exist, we will add the transaction to any of the block files that are located in the backend servers.
Phase 2B: Main Server computes the operation and replies to the client.
Once the connection server (or the main server) receives the relevant data for the desired operation from the other three servers (namely serverA, serverB and serverC), it will perform the required computation and send the results to the clients. The computation performed by the main server depends on the service requested by the clients (i.e, CHECK WALLET or TXCOINS)
Operation1: CHECK WALLET
In this operation, the main server would be receiving only those transaction logs from each of the three backend servers (serverA, serverB and serverC) in which the client was involved. There can be multiple transaction logs related to a particular client

distributed randomly across the three log files. Each backend server would be handling it’s own log file.
Based on the log data (mentioned above) received, the main server will compute the current balance of the client based on the following formula :
𝐶𝑢𝑟𝑟𝑒𝑛𝑡 𝐵𝑎𝑙𝑎𝑛𝑐𝑒 = 𝐼𝑛𝑖𝑡𝑖𝑎𝑙 𝐵𝑎𝑙𝑎𝑛𝑐𝑒 + ∑ 𝐶𝑜𝑖𝑛𝑠 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑑 − ∑ 𝐶𝑜𝑖𝑛𝑠 𝑆𝑒𝑛𝑡
As already mentioned in phase 2A, initially all the members would be having 1000 alicoins. So, ‘Initial Balance’ for everyone would be 1000.
After computing the current balance for a client, the main server will send this info to that respective client.
Operation2: TXCOINS
In this operation, the main server would notify the client about the transaction status. The transaction can either be successful or unsuccessful. In either case, the main server should notify the client about the status.
The transaction can be unsuccessful mainly because of two reasons. The first one being insufficient current balance of the sender. Transactions can also fail if either sender or recipient (or both) is not part of the network.
If the transaction is feasible (both the sender and the receiver are part of the network and the sender’s balance is equal to or more than what he/she is intending to send), the main server would perform the following computations:
● The main server would figure out what should be the serial number of the current transaction. Every transaction would have a serial number which should be assigned in a contiguous fashion as they occur. In the log files, these transactions would not be arranged in some specific order of their serial number as the transaction log data is randomly distributed across three log databases handled by the three backend servers (serverA, serverB and serverC) separately. So, if the last transaction had a serial number ‘n’, then the current transaction should have the serial number of ‘n+1’.
● The main server would then generate the log entry (which would be similar to the the other logs):

● The main server then randomly selects any of the three backend servers (serverA, serverB and serverC) and sends this log entry to the selected server.

The server which receives this log information records this log information as a new entry in its log database and sends a confirmation message to the main server.
● Upon receiving the confirmation, the main server enquiries for the updated balance of the sender and sends the transaction status along with the updated balance (current balance after this transaction) to the sender client.
Phase 3: (30 points)
In phases 1 and 2 we have described two operations that required us to do calculations to check each user’s account balance and also to add transactions to the blockchain. For phase 3, we will add one more operation named TXLIST
Operation3: TXLIST
For this operation the client will send a keyword to indicate that the client is asking to get the full text version of all the transactions that have been taking place in Alichain and save it on a file named ”alichain.txt” located on the main server. The format of the operation will be as follows:
./clientATXLIST or ./clientBTXLIST
Either client should be able to handle this operation. When the client runs this operation, main server will receive this request and connect to the backend servers to gather all the information from the transactions. Main server will sort the list of transactions and generate the “alichain.txt” file with all the transactions made up to that point (including any new transactions made from the moment we booted up the servers). Students will have the freedom to choose any algorithm they prefer for this sorting operation.
Phase 4: (10 points extra, not mandatory)
If you want to earn 10 extra points, you can implement an extra operation where either client provides a statistical result with a summary of all the transactions and provides a list of all the users the client has made transactions with usernameA. This operation cannot be done separately, i.e, it should be on the same command line “./clientA stats”. For example, for username Ali when running the command:
./clientA Ali stats

Table 2: An example of the stats file format for phase 4
Number of transactions made with user
Transfer Amount
ClientA will receive this information and print it on screen. The results should be ranked based on the number of times the user has made or received a transaction from each user. The transfer amount is the resulting balance from all the transactions made between the username we are requesting the stats from and the other it has interacted with.
NOTE: The extra points will only work when you don’t get full 100 points. The maximum points for this socket programming project is only 100. For example, you get 97 + 10 = 100.
Required Port Number Allocation
The ports to be used by the clients and the servers for the exercise are specified in the following table:
Table 3. Static and Dynamic assignments for TCP and UDP ports.
Dynamic Ports
Static Ports
Backend-Server (A)
1 UDP, 21000+xxx
Backend-Server (B)
1 UDP, 22000+xxx

Backend-Server (C)
1 UDP, 23000+xxx
Main Server (M)
1 UDP, 24000+xxx
1 TCP with client A, 25000+xxx 1 TCP with client B, 26000+xxx


NOTE: xxx is the last 3 digits of your USC ID. For example, if the last 3 digits of your USC ID are “319”, you should use the port: 21000+319 = 21319 for the Backend-Server (A). It is NOT going to be 21000319.
ON SCREEN MESSAGES:
Table 4. Backend-Server A on screen messages
On Screen Message (inside quotes)
Booting Up (Only while starting):
“The ServerA is up and running using UDP on port .”
Upon Receiving the request from main server
“The ServerA received a request from the Main Server.”
After sending the results to the main server:
“The ServerA finished sending the response to the Main Server.”
ON SCREEN MESSAGES:
Table 5. Backend-Server B on screen messages
On Screen Message (inside quotes)
Booting Up (Only while starting):
“The ServerB is up and running using UDP on port .”
Upon Receiving the request from Main Server
“The ServerB received a request from the Main Server.”
After sending the results to the main server:
“The ServerB finished sending the response to the Main Server.”
ON SCREEN MESSAGES:
Table 6. Backend-Server C on screen messages
On Screen Message (inside quotes)

Booting Up (Only while starting):
“The ServerC is up and running using UDP on port .”
Upon Receiving the request from main server
“The ServerC received a request from the Main Server.”
After sending the results to the main server:
“The ServerC finished sending the response to the Main Server.”
ON SCREEN MESSAGES:
Table 7. Main Server on screen messages
On Screen Message (inside quotes)
Booting Up (only while starting):
“The main server is up and running.”
Upon Receiving the username from the clients for checking
“The main server received input= from the client using TCP over port .”
Upon Receiving the username from the clients for transferring coins:
“The main server received from to transfer coins to
using TCP over port .”
After querying Backend-Server i for checking balance ( i is one of A,B, or C):
“The main server sent a request to server .”
After receiving result from backend server i for checking balance (
i is one of A,B, or C):
“The main server received transactions from Server using UDP over port .”