Chat Server description

The three files I have just pasted here - server.c, client.c, and chat.c - are the prototype for a chat server architecture that I am building.  I basically coded the entire thing in one night, after teaching myself how to use the System V IPC constructs.  I haven't tested it yet, so expect it to be full of bugs if you actually go ahead and compile it.  It is complete, however, in the sense that aside from any bugs it may have, it has all of the necessary components for a fully functional chat server.  It is loosely based on IRC, borrowing several concepts from that protocol - like real-time updates (achieved through the SIGPOLL signal), nicks for each user, and a mechanism for "kicking" users from the chatroom.  The biggest difference is probably the implementation.  Whereas IRC requires a special IRC client to be able to use it, the chat server architecture I have created has both the chat client and the chat server running on a single central server.  In this way it more closely emulates a classic time-sharing architecture than a modern client-server architecture.  All you need to access a chatroom is an SSH client.  You log in as a regular user and then run the chat client on the remote machine as if it were a local program.  There is one server, and each user who logs in is given a single client.  The clients communicate with the server through a common message queue, and chat messages are logged in a shared memory region by the server, where they can be read by the clients.  I believe this will make it faster than communication through sockets, disregarding of course the obvious limitation that users are still logging in over a network.

When I posted this set of files, I was surprised to see it got over 70 hits in the first few minutes.  I guess this site is just really popular.  Maybe I'll actually get some feedback on my shit.  It's my first fully functional program that I've written in C that isn't just a simple command line utility.  I attribute this success to a new approach I'm taking to C coding - an approach that involves first planning out how a program will be implemented, then implementing it from either a top-down approach (starting with the outermost functions) or a bottom-up approach (starting with the most primitive operations).  I find both work, though the latter makes for easier testing.  This particular program was implemented top-down.  I basically just coded nonstop from 10:00 PM to 7:00 AM.  I have made sure to break the program up into as many functions as possible, and have succeeded in limiting all functions to no more than 15 lines (not counting whitespace, comments, and the function heading and last curly bracket).  This will make it much less of a pain in the ass to debug.  Indeed, I was even able to catch a number of bugs before I even got to the testing phase, simply by looking at the code.  The main() function is literally self-documenting, being nothing more than a list of function calls with descriptive names, followed by a return 0.  Of course one limitation of having many small functions is the number of data items you have to pass between them.  I have solved this by simply making many of the variables global.  That's basically how this thing works.  I look forward to working on it some more, maybe fleshing it out with more commands.