CS5133-Project 3 Reliable Multicast Broadcast using UDP Solved

The objective of this programming project is to learn UDP reliable client-server interaction using UDP socket interface. After completing the project, you will have a basic understanding of the steps required to add reliability features in UDP applications for developing a networking application. 

2.    Project Specification: 

Multicast only applies to UDP, which is connectionless and provide no reliability. Multicast is unreliable as there is no guarantee that every multicast message destined for the same multicast group address will be received by every host subscribing to this multicast group. In order to fit the reliability needs of multicast applications, many schemes have been proposed. In this project, you are required to implement a Reliable Multicast Server and a Client in C language that implements a simple version of reliable multicasting. Allow up to 5 reliable clients to simultaneously subscribe to the multicast group served by your Reliable Multicast Server. Each of the subscribing clients will be executed on a distinct host in the CS GPEL machines, and the reliable multicast server will keep track of all current subscribed clients. Every time the server multicasts a message, it expects an acknowledgment from every subscribed client. If the server does not receive acknowledgments from all subscribing clients within a timeout period, the server will unicast the message to each subscribed client that fails to acknowledge. The server would not proceed to multicast the next message until it successfully receives an acknowledgment from every subscribed client.  

 

2.1. Multi-cast Server Behavior: 

•        At startup, the server takes an argument that specifies the port number that it is listening to. You have to use (5000+last 4 digits of your student-id number) to avoid requesting same port by multiple students.

•        After successful startup, the multi-cast server program will ask the user to create a group (e.g., OUCS) and maximum number of clients (e.g., 5) can join in the group to receive broadcast messages.

•        Next, your multicast server should prompt the user to enter the number of messages to be multicasted among clients. At the same time, your multicast server should listen for joining and leaving requests from the clients, until the user finishes inputting all messages.  

•        As clients may use the message “JOIN” to join the multicast group and “QUIT” to leave from the group, server needs to maintain the active client list for message broadcasting purpose. If the client is unable to join the multicast group, send an error message to client (e.g., more than maximum number of clients join the multicast group). If the client closes the connection, the server should remove this client from the active client list and print out the client IP + port information.

•        In order to simulate possible message loss, your multicast server and clients should “accept” only 90% received messages and discard the remaining 10%. The clients acknowledge only “accepted” messages, not all the received messages.  

•        Your multicast server will wait for 2 seconds for acknowledgments from its clients. After the timeout expires, the server starts unicasting the same message to those clients that fail to acknowledge this message (or whose acknowledgment is discarded by the server).

•        When sending out a message, your multicast server should display the content of the message, and whether the message is multicasted or unicasted. For example, “Content of the message, Multicasted to … or Content of the message, Unicasted to …”.  

•        When accepting a message, your multicast client should display the content of the message, along with a tag specifying whether the message is a multicast message or a unicast message (which is a retransmission).

•        Server requires to unsubscribe all clients from the group (e.g., OUCS) as soon as it receives the string “CLEARALL” from user input.

 

2.2. Client Behavior: 

•        Your client program needs to take two arguments from user during startup that specifies the IP address and port number of the multi-cast server it wants to access.  

•        After a successful startup, your sender program will first prompt a welcome message that asks the user to input a group name (e.g., OUCS) it wants to join.  

•        Next, client requires to send the message “JOIN” to join the multicast group to receive messages from the multi-cast server.  

•        Similarly, client can send the message “QUIT” to unsubscribe from the group and receive no further messages from the server. 

•        When accepting a message, your multicast client should display the content of the message, along with a tag specifying whether the message is a multicast message or a unicast message (which is a retransmission).

•        In order to simulate possible message loss, your clients should “accept” only 90% received messages and discard the remaining 10%. The clients acknowledge only “accepted” messages, not all the received messages. Note: multi-cast server also randomly discards 10% of received acknowledgements from clients.  

•        After client accepts a message, it needs to send an acknowledgement message “RECEIVED” to the multicast server.