EE450 Socket Programming Project, Spring 2022
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
EE450 Socket Programming Project, Spring 2022
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: The name of this piece of code must be clientA.c or clientA.cc or 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: The code file for the monitor must be called clientB.c or clientB.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. |
Sender |
Receiver |
Transfer Amount |
1 |
Racheal |
John |
45 |
2 |
Rishil |
Alice |
30 |
3 |
Oliver |
Rachit |
94 |
4 |
Ben |
Victor |
85 |
5 |
Chinmay |
Oliver |
129 |
6 |
Racheal |
Alice |
49 |
7 |
Martin |
Luke |
25 |
8 |
Rishil |
Chinmay |
10 |
9 |
Ali |
Luke |
155 |
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:
./clientA TXLIST or ./clientB TXLIST
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
./clientA Ali stats
Table 2: An example of the stats file format for phase 4 |
|||
Rank |
Username |
Number of |
Transfer Amount |
1 |
Racheal |
15 |
355 |
2 |
Alice |
10 |
280 |
3 |
Oliver |
8 |
35 |
4 |
Ben |
5 |
-240 |
5 |
Chinmay |
3 |
-100 |
6 |
Luke |
1 |
30 |
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.
2022-03-05