IPv4 addressing
The implementation uses AF_INET and a sockaddr_in structure for IPv4 socket addressing.
← Back to projects
Project 07 / Systems programming / Networking
Real-Time Chat Application
Exploring low-level networking in C through a TCP-based chat system that establishes client-server connections and enables interactive message exchange.
01 · ClientTCP Client127.0.0.1 · port 8080
→
02 · TransportTCP ConnectionIPv4 · SOCK_STREAM
→
03 · ServerTCP Serverlisten · accept · exchange
Messagewrite()send text buffer
↔
Messageread()receive text buffer
The provided implementation accepts one client connection and then performs synchronous request-response-style message exchange over the established socket.
The problem
Understand how separate processes establish a reliable communication channel.
Even a small messaging program has to create sockets, assign network addresses, establish a connection, move data in both directions, and decide when a session should end. The project uses a terminal chat prototype to make that network lifecycle visible without relying on a high-level messaging framework.
The solution
Build two C programs around a direct TCP client-server connection.
The server creates an IPv4 TCP socket, binds and listens, then accepts one incoming client. The client creates its own socket and connects to the server on localhost. Once the connection is established, both programs exchange text through simple buffers using read() and write().
socket()→bind()→listen()→accept()↔connect()→read / write→exit
System architecture
A deliberately small networking model makes the TCP lifecycle easy to inspect.
TCP ClientAF_INET · SOCK_STREAM
→
127.0.0.1:8080local TCP connection
→
TCP Serverbind · listen · accept
TCP stream socket
SOCK_STREAM selects TCP-style reliable byte-stream communication instead of datagrams.
Local test setup
The client source targets 127.0.0.1 on port 8080, keeping the demonstrated communication on the local machine.
Implementation breakdown
Follow the socket lifecycle explicitly on both sides of the connection.
TCP server
The server calls socket() to create the descriptor, bind() to associate it with an address and port, listen() to enter passive listening mode, and accept() to obtain the connected client socket.
TCP client
The client creates a matching IPv4 stream socket and uses connect() with localhost and port 8080 to initiate the session.
Bidirectional messaging
Both programs use fixed-size character buffers. The client writes a message and reads the server response; the server reads the client message and writes its reply.
Session termination
The communication loop checks for the text exit and breaks when that termination condition is encountered. The source demonstrates a basic learning-oriented shutdown condition rather than comprehensive disconnect handling.
Actual application demonstration
Follow the same TCP conversation from the server and client terminals.
The original full-resolution academic screenshot has been separated into two independent images so each side is easier to read. Click to open the full-screen viewer.
Both captures show one synchronous client-server session. The report does not demonstrate multi-client concurrency.
Code highlights
Small excerpts show the connection lifecycle without reproducing pages of source code.
sockfd = socket(AF_INET, SOCK_STREAM, 0);
bind(sockfd, (SA*)&servaddr, sizeof(servaddr));
listen(sockfd, 5);
connfd = accept(sockfd, (SA*)&cli, &len);servaddr.sin_addr.s_addr = inet_addr("127.0.0.1");
servaddr.sin_port = htons(PORT);
connect(sockfd, (SA*)&servaddr, sizeof(servaddr));write(sockfd, buff, sizeof(buff));
read(sockfd, buff, sizeof(buff));
if (strncmp(buff, "exit", 4) == 0) {
break;
}Engineering challenges explored
Working close to the socket API makes connection state and message handling explicit.
01 · Understanding socket communication
Working directly with TCP sockets requires understanding descriptors, addresses, connection setup, and the lifecycle of a network session.
02 · Coordinating client and server
The server has to create, bind, and listen before the client can successfully establish the connection, making initialization order important.
03 · Managing message exchange
The loop explicitly handles buffers, incoming reads, outgoing writes, and the termination condition instead of delegating those responsibilities to a messaging framework.
Results
A working foundation in network programming.
Server lifecycle demonstrated
The server creates a TCP socket, binds, listens, accepts a client, and enters the chat loop.
Client connection demonstrated
The client targets localhost on port 8080, connects, and participates in the terminal conversation.
Bidirectional communication
The report screenshots show interactive text moving in both directions and a demonstrated exit termination condition.
The report discusses multithreading and concurrent communication as broader project goals, but the supplied server code shown in the report performs one accept() and does not demonstrate a thread-per-client or event-driven multi-client implementation. This case study therefore describes the implementation as a synchronous single-client prototype.
Limitations & future improvements
Use the prototype as a base for more realistic network-server design.
Multiple clients
Add threads or event-driven I/O and define how messages are broadcast or routed between connected users.
Protocol robustness
Handle partial reads/writes, explicit message framing, stronger error paths, and unexpected disconnects.
Identity & transport security
Add username/session management plus authenticated and encrypted connections rather than treating a raw socket as a complete messaging service.
Key learnings
An early project that made backend communication less abstract.
Building the chat prototype provided hands-on exposure to C, client-server architecture, TCP/IP fundamentals, Linux/POSIX socket APIs, network connection lifecycle, buffer management, and the need for an application-level communication protocol. That foundation is useful when reasoning about higher-level backend and networked applications later on.
The assignment report credits Asmita G V and Divya O N as collaborators. The source does not document a reliable split of individual responsibilities, so this page does not imply sole authorship.