Designing a Scalable C Chat Server

[James889]

Hi,

I developed a simple ad-hoc client/server chat program, however the design isn't exactly scalable since the addresses are hard coded and one of the clients is also the server.

So i wanted to write a dedicated server, to which multiple clients could connect and chat, like irssi..

how would you design something like this?

 

[chiro]

Hey James889.

I did a design quite a while ago for networked protocols and the way I designed it was to use a callback system (think event system) where you created servers and clients where clients connected to servers with a global manager and any external program could register with these frameworks to get messages.

The registration method is known as Publish/Subscribe in the programming world and its just a fancy way of giving callbacks with the events that you want to subscribe to, to the framework so it can call the callbacks when something happens.

So in short, you create a server object for the server, a client object on the other computer and behind the scenes you have some way of sending and receiving data that is standardized for all network messages.

The way I did was that I used the select function, but there are way better ways to do the same thing in both Winsock and in the normal sockets library: I used it because I was familiar with it and because it worked but apparently some people say that using select is bad for performance.

What happens is that each connection has an internal double buffer and in the back-ground the client connection thread is both sending the data as soon as it can to where-ever and receiving data when it can.

All network messages have a standard header and as soon as the thread gets a complete packet (details are in the header) it constructs the packet and constructs a packet class using a class factory in which it creates the class and asks the class to handle that packet.

The class then does its thing and handles the packet by transforming the data into its own structures and it does whatever it needs to.

So in this scenario you have a chat-message-protocol packet and then you can put it whatever routines and information inside that packet.

The point of doing this is that the standard framework takes care of getting packets, constructing them, checking them for errors and then asking a specific interface to execute them. You can block packet-types directly from the centralized interface that you don't want and you can also do 3rd party stuff where you can say download a DLL or an SO and implement custom packet handling by an extension.

If you want to use UI routines then the appropriate modules subscribe to specific packet events, new network connections (client connections to a particular server) and other events to update the data in the UI and the module. Since this is all event based you just create the right publish/subscribe class which can be templated with a specific kind of data structure and register it with the network manager.

After you create the server, the UI and other systems register the events with the network manager given a server and the call-back method updates the UI and anything else.

That's the basic idea I used for doing network stuff and it worked really well. It takes a little bit of overhead to get it right, but when you do you can make everything modular that communicates with each other and updating the functionality is a lot easier as well.

 

[James889]

Ouch, sounds difficult.

 

[chiro]

You don't have to do everything at once: do it bit by bit and if you don't want the flexibility of one feature, then leave it out and leave the skeleton there if you want to add it in later.

The way I did it was specifically so that the whole thing could be extended without modifying the original executable: it was built to be extended by third party DLL's and other such extensions.

If you want to design programs for easy extensibility, you need to do this but if you not, you can make different design decisions.

 

[LudusRex]

Thank you for sharing your idea about designing a scalable C chat server. I would approach this problem by first identifying the key requirements and goals of the chat server. This could include factors such as the number of clients it needs to support, the expected traffic and message volume, and the desired level of reliability and scalability.

Based on these requirements, I would then start by designing the overall architecture of the chat server. This could involve breaking the system down into smaller components, such as a front-end server for handling client connections and a back-end server for managing chat messages. I would also consider using a distributed system approach, where multiple servers can work together to handle the load and provide redundancy.

Next, I would focus on designing the communication protocol between the clients and the server. This protocol should be efficient, secure, and able to handle multiple concurrent connections. I would also consider implementing features such as message encryption and authentication to ensure the privacy and security of the chat conversations.

In terms of scalability, I would design the server to be able to handle a large number of clients and messages without compromising performance. This could involve using techniques such as load balancing and distributed caching to distribute the workload across multiple servers.

Additionally, I would pay attention to error handling and fault tolerance in the design. The chat server should be able to detect and handle errors gracefully to ensure uninterrupted communication between clients.

Overall, designing a scalable C chat server would require careful planning and consideration of various factors such as performance, security, and reliability. It would also be important to continuously test and optimize the system to ensure it can handle the expected load and meet the desired goals.