CatChat Logo
SourceForge Logo
Home | Project


Technical summary:

CatChat is a peer-to-peer chat application. This simply means that there is no central server in charge of hosting a chat room. Instead, anybody running CatChat could be a client connected to a chat server and could also act as a chat server (if it is possible for the client to do so). This decentralizes the chat room process taking away the need for a central server.

This causes a few problems. For one thing, with no central server how do you find the chat room at all? Well after thinking about it for a while I came up with one simple fact: If you want to be able to find a chat server AND the network is relatively small, you are going to need a server with a static IP address to act as a host and must maintain a list of servers. Upon thinking about it a little more, I thought that it would be simple to just create a CGI script or JSP servlet to manage a list of servers in a given chat room. (problem solved?)

Secondly, how do the peers connect to each other? What kinds of problems arise? If you have ever seen the Gnutella protocol we see that all this network is is a collection of peers connected to each other rather randomly. In other words, this is a network with the problem that the connections can contain cycles.

Does it make sense for a small network to contain cycles? How does this affect chat rooms? The answer is easy. If the network has cycles, messages that are broadcast to many users using a protocol like Gnutella will be seen more than one time (unless we prevent sending messages that we have already seen). This does not make sense. In a small network I can prevent cycles by controlling which peer you connect to. (this causes another series of problems, but these are relatively easy to fix...). (NOTE: I will provide a picture of this later. . .)

So what shape does this network take on? Well, the shape will still be relatively random, but will look more like a tree. The idea is to limit the number of peers one given node in the network will connect to while shortening the distance between each node. So, a bunch of peers connected together in a straight line has the problem that each message must travel from one end of the network to the other. Similarly all peers could connect to once central node. The problem with this is that one peer must manage all of the connections. If they are on a slow network, this will be a bottleneck. (NOTE: I will provide a series of pictures to explain the different network configurations and their advantages/disadvantages.)