Description
Reference Text Book:
“Unix Network Programming”, Volume 1, by W. Richard Stevens (publisher: Prentice Hall) (refer to first
few chapters)
Table 1: Allocation of applications to groups
1
Application Name Group Numbers
1 Banking System 1, 2, 11, 20, 29, 38
2 Trading System 3, 12, 21, 30, 39, 47
3 Base64 Encoding System 4, 13, 22, 31, 40, 48
4 DNS Resolving System 5, 14, 23, 32, 41, 49
5 TCP and UDP Sockets 6, 15, 24, 33, 42
6 Peer-to-Peer System 7, 16, 25, 34, 43
7 Point-of-Sale Terminal 8, 17, 26, 35, 44
8 Error Detection using CRC 9, 18, 27, 36, 45
9 File Transfer Protocol 10, 19, 28, 37, 46
Application
ID
Application ID 1: Banking System using Client-Server socket programming
In this application, you require implementing two C programs, namely Client and Bank Server, and they
communicate with each other based on TCP sockets. The goal is to implement a simple Banking System.
Initially, the client will connect to the bank server using the server’s TCP port already known to the client. After
successful connection, the client sends a Login Message (containing the Username and password) to the bank
server. The client side, we can have three different types of user modes namely, Bank_Customer, Bank_Admin
and Police. The bank server has the following files with him: Login_file (contains the login entries, assume
limited number of static entries only), Customer_Account_files (Assume the bank has 10 Bank_Customers only
and one file for each customer, which maintains the transaction history. Refer to Login_file and
Customer_Account_files formats for more details). Once the Bank server receives the login request, it validates
the information and performs the functionalities according to the user mode type. The system must provide the
following functionalities to the following users:
Bank_Customer: The customer should able to see AVAILABLE BALANCE in his/her account and MINI
STATEMENT of his/her account.
Bank_Admin: The admin should be able to CREDIT/DEBIT the certain amount of money from any
Bank_Customer ACCOUNT (as we do it in a SBI single window counter.). The admin must update the
respective “Customer_Account_file” by appending the new information. Handel the Customer account
balance underflow cases carefully.
Police: The police should only be able to see the available balance of all customers. He is allowed to
view any Customers MINI STATEMENT by quoting the Customer _ID (i.e. User_ID with user_type as ‘C’).
Login_file entry format:
User_ID Password User_Type (C/A/P)
Customer _Account_files entry format:
Transaction_Date Transaction Type (Credit/Debit) Available Account_Balance
Implement the functionalities using proper REQUEST and RESPONSE Message formats. After each negotiation
phase, the TCP connection on both sides should be closed gracefully releasing the socket resource. You should
accept the IP Address and Port number from the command line (Don’t use a hard-coded port number).
Prototype for command line is as follows:
Prototypes for Client and Server
Client:
Server:
NB: Please make necessary and valid assumptions whenever required.
2
Application ID 2: Client Server Trading System using socket programming
A Client-Server Based Trading System is to be designed with the following specifications. There will be a set of
traders who will trade with each other in the automated system. There will be a Server which will register
requests from traders for buying and selling quantities of Items. The Server will also match the buy with the sell
requests from different traders based on certain price rules (as listed below). Traders will log on to the trading
system through the trading client (assume Trader ID and password is stored in a file). They will have the option
to view the currently available items (for buy/sell), their quantities and their prices. They will also send
requests for buying and selling items and specify the quantity and price. Traders will also have the option to
view their matched trades at any time. There are ten known items which the traders can trade in with their
codes from 1 to 10. There will be a maximum of 5 traders (with codes from 1 to 5) who can log on to the system
and work. One trader should work from one client at a time only.The functionalities of any client will be:
Login to the System: The trader will execute the client, give the trader number and will be logged in.
After that he/she will have the following options in a menu. Several clients will login (from different
terminals) and assumed they don’t trade simultaneously to reduce the complexity.
Send Buy Request: The trader will send a buy request by stating the item code, the quantity and unit
price.
Send Sell request: The trader will send a sell request by stating the item code, the quantity and unit
price.
View Order Status: The Trader can view the position of buy and sell orders in the system. This will
display the current best sell (least price) and the best buy (max price) for each item and their quantities.
View Trade Status: The trader can view his/her matched trades. This will provide the trader with the
details of what orders were matched, their quantities, prices and counterparty code.
There will be only one server which will be running and perform the functions of order processing and trade
matching in addition to acknowledging logins by clients and servicing their requests. The order processing will
be as follows. There will be a buy and a sell order queue for each item. On receiving buy/sell order request from
a trader, the server will put it in the appropriate order queue. If there is a possibility of a trade match, then that
trade match will take place, the traded items will be appropriately updated and the result of the trade along
with the details of the counterparties, item, quantity and price will be stored in the traded set. The matching
rule is as follows:
1. On a buy Request at price P and quantity Q of an item I, the server will check if there is any pending sell
order for the same item at price P’ ≤ P.
2. Among all such pending sell orders, the match will be made with the one having the least selling price.
3. If both have same quantity, i.e., Q’= Q, then both these orders will be removed from their respective
queues and the result will be put into the traded set.
4. If Q’ > Q then the buy request will be fully traded and the remaining part, i.e., Q’ – Q of the sell order will
remain in the sell queue at the same price P’.
5. On the other hand, if Q’ < Q then the sell order will be fully traded and the remaining buy order will be
tested for more matches.
6. If the buy order cannot be matched, it will be put into the buy queue.
7. A similar rule will apply for a sell request and all these requests will be handled in a FCFS basis.
You should accept the IP Address and Port number from the command line (Don't use a hard-coded port
number). *Please make necessary and valid assumptions whenever required.
Prototype for command line is as follows:
Prototypes for Client and Server
Client:
Server:
3
Application ID 3: Base64 encoding system using Client-Server socket programming
In this application, you require to implement two C programs, namely server and client to communicate with
each other based on TCP sockets. The aim is to implement simple Base64 encoding communication protocol.
Initially, server will be waiting for a TCP connection from the client. Then, client will connect to the server using
server’s TCP port already known to the client. After successful connection, the client accepts the text input from
the user and encodes the input using Base64 encoding system. Once encoded message is computed the client
sends the Message (Type 1 message) to the server via TCP port. After receiving the Message, server should
print the received and original message by decoding the received message, and sends an ACK (Type 2 message)
to the client. The client and server should remain in a loop to communicate any number of messages. Once the
client wants to close the communication, it should send a Message (Type 3 Message) to the server and the TCP
connection on both the server and client should be closed gracefully by releasing the socket resource.
The messages used to communicate contain the following fields:
Message_ Type Message
1. Message_type: integer
2. Message: Character [MSG_LEN], where MSG_LEN is an integer constant
3.
You also require implementing a “Concurrent Server”, i.e., a server that accepts connections from multiple
clients and serves all of them concurrently.
You should accept the IP Address and Port number from the command line (Don’t use a hard-coded port
number).
Prototype for command line is as follows:
Prototypes for Client and Server
Client:
Server:
NB: Please make necessary and valid assumptions whenever required.
Base64 Encoding System Description:
Base64 encoding is used for sending a binary message over the net. In this scheme, groups of 24bit are broken
into four 6 bit groups and each group is encoded with an ASCII character. For binary values 0 to 25 ASCII
character ‘A’ to ‘Z’ are used followed by lower case letters and the digits for binary values 26 to 51 & 52 to 61
respectively. Character ‘+’ and ‘/’ are used for binary value 62 & 63 respectively. In case the last group contains
only 8 & 16 bits, then “==” & “=” sequence are appended to the end.
4
Application ID 4: Multi-stage DNS Resolving System using Client-Server socket
programming
In this application, you require implementing three C programs, namely Client, Proxy Server (which will act
both as client and server) and DNS Server, and they communicate with each other based on TCP sockets. The
aim is to implement a simple 2 stage DNS Resolver System.
Initially, the client will connect to the proxy server using the server’s TCP port already known to the client.
After successful connection, the client sends a Request Message (Type 1/Type 2) to the proxy server. The proxy
server has a limited cache (assume a cache with three IP to Domain_Name mapping entries only). After
receiving the Request Message, proxy server based on the Request Type (Type 1/Type 2) searches its cache for
corresponding match. If match is successful, it will send the response to the client using a Response Message.
Otherwise, the proxy server will connect to the DNS Server using a TCP port already known to the Proxy server
and send a Request Message (same as the client). The DNS server has a database (say .txt file) with it containing
set of Domain_name to IP_Address mappings. Once the DNS Server receives the Request Message from proxy
server, it searches in its file for possible match and sends a Response Message (Type 3/Type 4) to the proxy
server. On receiving the Response Message from DNS Server, the proxy server forwards the response back to
the client. If the Response Message type is 3, then the proxy server must update its cache with the fresh
information using FIFO scheme. After each negotiation phase, the TCP connection on both sides should be
closed gracefully releasing the socket resource.
Request Message Format:
Request_Type Message
Type 1: Message field contains Domain Name and requests for corresponding IP address.
Type 2: Message field contains IP address and request for the corresponding Domain Name.
Response Message Format:
Response_Type Message
Type 3: Message field contains Domain Name/IP address.
Type 4: Message field contains error message “entry not found in the database”.
You should accept the IP Address and Port number from the command line (Don’t use a hard-coded port
number).
Prototype for command line is as follows:
Prototypes for Client and Server
Client:
Server:
NB: Please make necessary and valid assumptions whenever required.
5
Application ID 5: Client-Server programming using both TCP and UDP sockets
In this application, you require to implement two C programs, namely server and client to communicate with
each other based on both TCP and UDP sockets. The aim is to implement a simple 2 stage communication
protocol.
Initially, server will be waiting for a TCP connection from the client. Then, client will connect to the server using
server’s TCP port already known to the client. After successful connection, the client sends a Request Message
(Type 1 message) to the server via TCP port to request a UDP port from server for future communication. After
receiving the Request Message, server selects a UDP port number and sends this port number back to the client
as a Response Message (Type 2 Message) over the TCP connection. After this negotiation phase, the TCP
connection on both the server and client should be closed gracefully releasing the socket resource.
In the second phase, the client transmits a short Data Message (Type 3 message) over the earlier negotiated
UDP port. The server will display the received Data Message and sends a Data Response (type 4 message) to
indicate the successful reception. After this data transfer phase, both sides close their UDP sockets.
The messages used to communicate contain the following fields:
Message_Type Message_Length Message
1. Message_type: integer
2. Message_length: integer
3. Message: Character [MSG_LEN], where MSG_LEN is an integer constant
in Client will be a Type 3 message with some content in its message section.
You also require implementing a “Concurrent Server”, i.e., a server that accepts connections from multiple
clients and serves all of them concurrently.
You should accept the IP Address and Port number from the command line (Don’t use a hard-coded port
number).
Prototype for command line is as follows:
Prototypes for Client and Server
Client:
Server:
NB: Please make necessary and valid assumptions whenever required.
6
Application ID 6: Relay based Peer-to-Peer System using Client-Server socket
programming
In this application, you require implementing three C programs, namely Peer_Client, and Relay_Server and
Peer_Nodes, and they communicate with each other based on TCP sockets. The aim is to implement a simple
Relay based Peer-to-Peer System.
Initially, the Peer_Nodes (peer 1/2/3 as shown in Figure 1) will connect to the Relay_Server using the TCP port
already known to them. After successful connection, all the Peer_Nodes provide their information (IP address
and PORT) to the Relay_Server and close the connections (as shown in Figure 1). The Relay_Server actively
maintains all the received information with it. Now the Peer_Nodes will act as servers and wait to accept
connection from Peer_Clients (refer phase three).
In second phase, the Peer_Client will connect to the Relay_Server using the server’s TCP port already known to
it. After successful connection; it will request the Relay_Server for active Peer_Nodes information (as shown in
Figure 2). The Relay_Server will response to the Peer_Client with the active Peer_Nodes information currently
having with it. On receiving the response message from the Relay_Server, the Peer_Client closes the connection
gracefully.
In third phase, a set of files (say, *.txt) are distributed evenly among the three Peer_Nodes. The Peer_Client will
take “file_Name” as an input from the user. Then it connects to the Peer_Nodes one at a time using the response
information. After successful connection, the Peer_Client tries to fetches the file from the Peer_Node. If the file is
present with the Peer_Node, it will provide the file content to the Peer_Client and the Peer_Client will print the
file content in its terminal. If not, Peer_Client will connect the next Peer_Node and performs the above action.
This will continue till the Peer_Client gets the file content or all the entries in the Relay_Server Response are
exhausted (Assume only three/four Peer_Nodes in the system).
Implement the functionalities using appropriate REQUEST and RESPONSE Message formats. After each
negotiation phase, the TCP connection on both sides should be closed gracefully releasing the socket resource.
You should accept the IP Address and Port number from the command line (Don’t use a hard-coded port
number).
Prototype for command line is as follows:
Prototypes for Client and Server
Client:
Server:
NB: Please make necessary and valid assumptions whenever required.
7
Application ID 7: Point-of-Sale Terminal using socket programming
Use socket programming to implement a simple client and server that communicate over the network and
implement a simple application involving Cash Registers. The client implements a simple cash register that
opens a session with the server and then supplies a sequence of codes (refer request-response messages
format) for some products. The server returns the price of each one, if the product is available, and also keeps a
running total of purchases for each client’s transactions. When the client closes the session, the server returns
the total cost. This is how the point-of-sale terminals should work. You can use a TXT file as a database to store
the UPC code and item description at the server end.
You also require implementing a “Concurrent Server”, i.e., a server that accepts connections from multiple
clients and serves all of them concurrently.
Request-response messages format
Request_ Type UPC-Code Number
Where
• Request_Type is either 0 for item or 1 for close.
• UPC-code is a 3-digit unique product code; this field is meaningful only if the Request_Type is 0.
• Number is the number of items being purchased; this field is meaningful only if the Request_Type is 0.
For the Close command, the server returns a number, which is the total cost of all the transactions done by the
client. For the item command, the server returns:
Response_ Type Response
Where:
If OK, then
o if client command was “close”, then
o if client command was “item”, then
where
If error, then
errors are “Protocol Error” or “UPC is not found in database”.
You should accept the IP Address and Port number from the command line (Don’t use a hard-coded port
number).
Prototype for command line is as follows:
Prototypes for Client and Server
Client:
Server:
The connection to the server should be gracefully terminated. When the server is terminated by pressing
Control+C, the server should also gracefully release the open socket (Hint: requires use of a signal handler).
NB: Please make necessary and valid assumptions whenever required.
8
Application ID 8: Error Detection using Cyclic Redundancy Code (Using CRC-8)
In this application, your aim will be to implement a simple Stop-and-Wait based data link layer level logical
channel between two nodes A and B using socket API, where node A and node B are the client and the server
for the socket interface respectively. Data link layer protocol should provide the following Error handling
technique in Data Link Layer.
– Error Detection using Cyclic Redundancy Code
(using CRC-8 as generator polynomial, i.e. G(x) = x8+x2+x+1)
Operation to Implement:
Client should construct the message to be transmitted (T(x)) from the raw message using CRC.
At the sender side T(x) is completely divisible by G(x) (means no error), send ACK to the sender,
otherwise (means error), send NACK to the sender.
You must write error generating codes based on a user given BER or probability (random number
between 0 and 1) to insert error into both T(x)and ACK/NACK.
If NACK is received by the sender, it should retransmit the T(x) again following the above steps.
In the client side also implement Timer Mechanism to detect the timeout (in case of error in ACK/
NACK) and retransmit the message T(x) again once time out happens.
You also require implementing a “Concurrent Server”, i.e., a server that accepts connections from multiple
clients and serves all of them concurrently.
You should accept the IP Address and Port number from the command line (Don’t use a hard-coded port
number).
Prototype for command line is as follows:
Prototypes for Client and Server
Client:
Server:
The connection to the server should be gracefully terminated. When the server is terminated by pressing
Control+C, the server should also gracefully release the open socket (Hint: requires use of a signal handler).
NB: Please make necessary and valid assumptions whenever required.
9
Application ID 9: File Transfer Protocol (FTP) using Client-Server socket programming
In this assignment, you require to implement two C programs, namely server and client to communicate with
each other based on TCP sockets. The goal is to implement a simple File Transfer Protocol (FTP). Initially,
server will be waiting for a TCP connection from the client. Then, client will connect to the server using server’s
TCP port already known to the client. After successful connection, the client should be able to perform the
following functionalities:
PUT: Client should transfer the file specified by the user to the server. On receiving the file, server
stores the file in its disk. If the file is already exists in the server disk, it communicates with the client to
inform it. The client should ask the user whether to overwrite the file or not and based on the user
choice the server should perform the needful action.
GET: Client should fetch the file specified by the user from the server. On receiving the file, client stores
the file in its disk. If the file is already exists in the client disk, it should ask the user whether to
overwrite the file or not and based on the user choice require to perform the needful action.
MPUT and MGET: MPUT and MGET are quite similar to PUT and GET respectively except they are used
to fetch all the files with a particular extension (e.g. .c, .txt, etc.). To perform these functions both the
client and server require to maintain the list of files they have in their disk. Also implement the file
overwriting case for these two commands as well.
Use appropriate message types to implement the aforesaid functionalities. For simplicity assume only .txt and .c
file(s) for transfer.
You should accept the IP Address and Port number from the command line (Don’t use a hard-coded port
number).
Prototype for command line is as follows:
Prototypes for Client and Server
Client:
Server:
NB: Please make necessary and valid assumptions whenever required.
Please find the Group ID and assigned Application ID for the formed groups in the
below table starting from next page:
10
11
Group ID Roll Name
1150123034 ROHIT KUMAR 1
1170123014 BARISH BHAGAT 1
1170123026 KONDRU SURAJ 1
1170123006 ANKIT TRIPATHI 1
2170101055 ROHAN NIGAM 1
2170123036 MOHIT DHAKA 1
2170123037 MOHIT KUMAR MEENA 1
3170101005 AMAN MISHRA 2
3170101031 KEERTI HARPAVAT 2
3170101049 Priyanshu Singh 2
4170101081 UDBHAV CHUGH 3
4170123013 BAGAL SATEJ BABANRAO 3
4170123052 TANYA CHAUHAN 3
5170123015 BOJJA SAI PREETHAM 4
5170123024 KESHETTI SAI KUMAR 4
5170123031 MALISETTI KIRAN KARTHEEK 4
6170101036 MANI MANNAMPALLI 5
6170101068 SUNNY KUMAR 5
6170101087 SIDDHARTH AGARWAL 5
7170101084 MAYANK BARANWAL 6
7170123017 DEV PRIYA GOEL 6
7170123059 SHRUTI DINESH AGARWAL 6
8170101035 MANAN GUPTA 7
8170123011 ASHISH AGARWAL 7
8170123038 MRIGANKA BASU ROY CHOWDHURY 7
9170101043 PARTHA PRATIM MALAKAR 8
9170101048 PRANSHU SRIVAS 8
9170101070 THAHIR MAHMOOD POOVADA 8
10170101039 NAGULAPALLI KASI VENKATA SAI KIRAN 9
10170101051 RAJANALA HARSHAVARDHAN REDDY 9
10170123016 CHINDAM SUJANA MAITHILI 9
11170101029 KAPIL JANGID 1
11170101044 PARVINDAR SINGH 1
11170101057 RUTVIK GHUGHAL 1
12170101077 VEMURI SAHITHYA 2
12170123039 NAKKA LAHARI 2
12170123054 TUMARADA ADITYA 2
13170101054 RISHI PATHAK 3
13170101063 SHIVAM BANSAL 3
13170101088 SHASHANK SHARMA 3
14170101040 NAKKA SRIHARSHA 4
14170123025 KOMMINENI NIKHIL 4
14170123028 KRISHNA PRIYATAM D 4
15170101001 AAYUSH PATNI 5
15170101052 RASHI SINGH 5
15170101066 SOUMIK PAUL 5
16170101033 LUCKY 6
16170101034 MAKHARIA AAYUSH 6
16170123021 HEMANT YADAV 6
Application ID
Assigned
12
Group ID Roll Name
17170123004 ADITYA RAJ 7
17170123040 PARV SOOD 7
17170123043 SAHILPREET SINGH THIND 7
18160101011 AKHIL CHANDRA PANCHUMARTHI 8
18170101017 CH ROHITH RAVI PRABHU TEJA 8
18170101050 PULIKONDA ROOP SAI RAKESH GUPTA 8
19170101006 AMAN RAJ 9
19170123029 KUSHAGRA MAHAJAN 9
19170123034 MIHIR YADAV 9
20170101074 UMANG 1
20170123051 TANVI OHRI 1
20170123053 TEJASVEE PANWAR 1
21170101078 VINEET MALIK 2
21170101080 VIVEK KUMAR 2
21170101085 Sparsh Sinha 2
22170101019 CHIRAG GUPTA 3
22170101076 VAKUL GUPTA 3
22170101082 LAVISH GULATI 3
23170101026 HARDIK KATYAL 4
23170101030 KARTIK GUPTA 4
23170101075 UTKARSH JAIN 4
24170123023 KEDAR NATH 5
24170123056 PRATHIK.S.NAYAK 5
24170123064 AGNIV BANDYOPADHYAY 5
25170101060 SANCHIT 6
25170123018 GARVIT MEHTA 6
25170123020 harit gupta 6
26170101002 ABHISHEK JAISWAL 7
26170101038 MAYANK WADHWANI 7
26170123007 ANKUR PRAMOD INGALE 7
27170101067 SOURABH JANGID 8
27170101071 THEEGALA RAKESH REDDY 8
27170101073 TUSHAR RAJENDRA BHUTADA 8
28170101009 ANUBHAV TYAGI 9
28170101045 Piyush Gupta 9
28170101053 RAVI SHANKAR 9
29160101017 AUTONU KRO 1
29170101023 FUGARE ASHISH DILEEP 1
29170101027 KADAM KIRAN ZATINGRAO 1
30170101011 ARANYA ARYAMAN 2
30170101015 AVNEET SINGH CHANNA 2
30170101041 NAVEEN KUMAR GUPTA 2
31170101059 Sachin Giri 3
31170101061 SAYAK DUTTA 3
31170123010 ARYAN RAJ 3
32170101013 ARYAN AGRAWAL 4
32170101014 AVIRAL GUPTA 4
32170101022 DEVANSH GUPTA 4
Application ID
Assigned
13
Group ID Roll Name
33170101064 SHUBHAM KUMAR 5
33170101065 SHYAM SUNDAR RAV 5
33170101079 VINIT KUMAR 5
34170101037 MAYANK CHANDRA 6
34170101046 PRABHAT KUMAR 6
34170123050 SUMEDH RAVI JOURAS 6
35170123001 AAYUSH BANSAL 7
35170123057 KARTIK SETHI 7
35170123058 ARUN KUMAR 7
36170101008 ANNANYA PRATAP SINGH CHAUHAN 8
36170101012 ARPIT GUPTA 8
36170101086 SHIVANG DALAL 8
37170123027 KOTTA PREM SUJAN 9
37170123035 MOGILLAPALLI NIKHIL 9
37170123042 S SAI VAMSHI 9
38170101007 ANIKET RAJPUT 1
38170101020 DEEPAK GAMI 1
38170101047 PRANAY GARG 1
39170101056 ROUNAK PARIHAR 2
39170101058 RYTHUM SINGLA 2
39170101083 UTKARSH SANTOSH MISHRA 2
40170123060 TRIKAY NALAMADA 3
40170123061 MAHFOOZUR RAHMAN KHAN 3
40170123062 DIVYANSH MANGAL 3
41170123003 ABHINAV R 4
41170123008 ARAV GARG 4
41170123063 JOEL RAJA SINGH 4
42170101021 DEVAISHI TIWARI 5
42170123048 SIDDHANT SINHA 5
42170123022 JAYANT PATIDAR 5
43170123012 AYUSH DALIA 6
43170123033 MAYANK SAHARAN 6
43170123044 SAKSHI SHARMA 6
44170123002 ABHINAV ANAND 7
44170123041 RUPAM SAHU 7
44170123045 SAURABH KUMAR 7
45170123019 GARVIT SARJARE 8
45170123032 MANNE HEMA PRIYA 8
45170123046 SHALINI KUMARI 8
46170101004 AJINKYA SHIVASHANKAR SHIVASHANKAR 9
46170101025 HANSRAJ PATEL 9
46170101003 ADITYA VARDHAN GARA 9
47170101016 BANDAGONDA SHRI RAAM REDDY 2
47170101018 CHALUMURU BHAVANI DATT 2
47170101024 GEDDAM IKYA VENUS 2
48170101028 KANCHUGANTLA RHYTHM 3
48170101032 KETHAVATH NAVEEN 3
48170101042 NAYANJYOTI DEURY 3
49170101062 SAYALKUMAR SUBHASH HAJARE 4
49170101072 TIKARAM MEENA 4
49170123005 ANKIT KUMAR KANOJIYA 4
Application ID
Assigned