Client-Server Chat Model

Overview

This project was developed as a partner collaboration for our networking course. Together, we designed and implemented a client-server chat model based on the client–server architecture, while also documenting our work by answering a series of networking-related questions.

The goal of the project was to gain a deeper understanding of how chat protocols function, how data is transmitted between hosts, and how client–server interactions can evolve into peer-to-peer communication. By creating and testing this model, we explored concepts such as protocol design, persistent vs. non-persistent TCP connections, half-duplex communication, and application layer responsibilities.

Protocol Design

We named our custom chat protocol the Connection Established Protocol (CEP). The central idea behind CEP is that every piece of data sent between two hosts must be both received and acknowledged before communication continues. For example:

• The server acknowledges client messages using commands such as REGISTER, BRIDGE, REGACK, and BRIDGEACK.
• During the chat process, the first client waits in a wait state until it confirms that the second client has entered chat state. Once both are synchronized, communication begins.

This ensures a reliable, connection-established flow before any chatting occurs.

Key Features

• Application Layer Protocol: The chat protocol is designed at the application layer, while relying on TCP at the transport layer for reliable data transfer.
• Client-Server Communication: Clients connect to the server to register and request connections. The server processes requests and responds with acknowledgments.
• Peer-to-Peer Chatting: Once a bridge is established, clients communicate directly in chat mode.
• Half-Duplex Chat: Messages flow in one direction at a time, requiring one client to finish before the other can respond.

TCP Connection Model

• Client–Server: Uses a non-persistent TCP connection, since clients only connect to the server for specific actions (e.g., registering or bridging). After each request-response cycle, the connection is closed.
• Peer-to-Peer: Uses a persistent TCP connection, since maintaining a single long-lived connection during chatting avoids unnecessary overhead and ensures efficiency.

This design decision mirrors how real-world applications balance scalability (non-persistent server connections) with responsiveness (persistent peer-to-peer sessions).

Architecture

• Client Role: Initiates communication, registers with the server, and requests connections.
• Server Role: Waits for client connections, processes requests, and sends acknowledgments.
• Chat Mode: Once connected, peers switch between “reading” (acting like a server) and “writing” (acting like a client).

Future Improvements

To transition this project into a fully functioning server application, one of the key issues to address is the closing of TCP connections after each client–server request. In a real-world scenario, the server would need to maintain multiple open connections simultaneously, allowing multiple clients to register, bridge, and chat without interruptions.

Learning Outcome

This project provided us with hands-on experience in designing a custom chat protocol and building a functioning model of client–server and peer-to-peer communication. It deepened our understanding of networking fundamentals and gave us practical insight into how modern chat applications manage connections and message flow.