I ended up finishing the project for my networking class last night. I spent the entire night on Tuesday implementing a Remote Method Invocation (RMI) service for the application. That ended up taking me about 4 hours, and the project as a whole ended up taking around 10-15 hours of solid coding. The RMI implementation ended up being a lot easier than I thought it was going to be.
This application is coded in C#.
The goals:
- [met] Develop a Server and Client Chat Interaction
- [met] Develop a Server Directory that is implemented via RMI or RPC
- [met] [Extra Credit] Allow the directory to update the Active Server List for anybody who disconnected
Bugs:
There are a few bugs that I didn’t have time to iron out. One of which revolves around how data is sent from the Client side. If the client sends a message, and then receives a message, the next message that the client sends will fail to send.
Ignore grammatical errors…
The Server:

The server was actually implemented as a functional server/chat. Some people just developed a server, just to be a server. Where as, I wanted to build the application for expandability. I wrote it so that the admin of the server could have more options for the chat session. For example: Being able to monitor the chat, kicking people, locking the chat room, etc.
The server maintains a few threads, one of which listens for new connections. Once connection has been established, I create a new Client object that is completely taken care of by that object. This allowed me to keep track of all kinds of data on the user. Is the user still connected? What is the users name, IP Address, Port?
Another thread manages the Remote Message Invocation object, and sends/receives data to update the chat directory.
Overall, it’s pretty functional.
The Client:

The client, is simply the client. Once the user starts the client, they will need to either A) Refresh the Chat Directory, or B) Enter a known server location to connect too. But, if that server is actually running, then they’d know by refreshing the chat directory. All servers must register with the chat directory.
The Chat Directory:

This little puppy is bad ass, and no, not just because I didn’t shrink this image down like I did the others. RMI is a pretty interesting, and the way it works is sweet.
For simplistic sake, you basically create a library (.dll) that the server, client, and directory shares. That library allows each application to directly access the directory by simply creating a channel to communicate through. Very easy, coding wise.
For example, the server creates a new object based off of the library, which connects to the chat directory:
TcpChannel newChan = new TcpChannel();
ChannelServices.RegisterChannel(newChan, true);
remObject = (RemoteObject)Activator.GetObject(typeof(RMIService.RemoteObject), “tcp://localhost:8030/RemotingServer”);
From there, you have access to all of the Directories functions. So if you wanted to get the names of all of the chat rooms listed on the directory side, you would just type
private String[] chatRoomList = new string[20];
chatRoomList = remObject.getNames();
And now the Server side (or the client), would be updated.
So, yeah. This Directory maintains a list of chat rooms that the servers have started. Once the server starts, it registers with this directory, and the directory then used to update each the Server and the Client. If a server does end up quitting, then before the form closes, it sends a message to the directory saying “Bye, dude,” and the directory removes all association (name, ip, port), from the list.
Results:
It went well, and I’m thinking about continuing it to play around some more. We’ll see how the grader finds it.
If you’d like to tinker with it, throw me a message on AIM at <aim marine>. I would post executables and source, if it wasn’t for having a few bugs.
The Mysterious Vanishing act of Static Form Controls in C#:
This had me completely baffled for quite some time… For some reason, forms don’t really like static form controls. And, you really need static form controls if you want to manipulate any sort of control through a Thread. Now that I think about it, I probably could have called a function from the thread to update it… Hmm… But, yeah… When the form goes to reload, it throws away the controls that are static, and if you’re lucky, it’ll erase all code pertaining to the control as well. Nice, eh? There seems to be no solution that I know of, just C# not enjoying the fact that you’re making controls static one bit.