Write your own threaded discussion forum: The communications and server components, part 2

Learn how to implement a simple communications protocol to get our forum discussion group up and running

By Michael Shoffner, JavaWorld.com, 03/01/97

In last month's edition, we discussed the specifications of the Interchange client -- the applet parameters, the GUI, the modes of operation, and the user's identity -- and worked through the ForumLauncher and Forum classes to implement them. ForumLauncher displays the icon that stores the client app, while Forum presents the GUI and contains the majority of the app's logic. If you haven't already done so, click on the icon at the top of this article to see the discussion forum applet in motion.

I told you we were only going to do a brief review. If you're feeling a bit behind the eight ball on these topics, I recommend that you review last month's installment and brush up before running headlong in to this month's article.

Oh, and if it's Java code you want, you'll find the full source for the forum here.

Developing lines of communication

As we saw last month, our system is going to follow a simple communications protocol to read and post topics. This simple protocol moves thread listings from server to client and articles from client to server (and vice versa). The networking classes (ForumComm, ForumConnectionHandler, and ForumServer), which we'll cover in detail shortly, will implement the following actions:

• "Load all threads" retrieves all current threads from the server.
• "Load all articles in thread T" retrieves all the articles in thread T from the server.
• "Post article A to thread T" posts article A to the server under thread T.

The client drives the server's actions with requests. The client will likely make very few requests over the course of its life; users typically spend the majority of session time reading articles and composing posts. For this reason, as well as the fact that requests are all discreet in nature (as opposed to transmission of real-time data, for example), each client request is serviced in a single connection, which is then closed down. The other alternative -- leaving a connection open between each client and the server for some specified period of time -- would waste precious server resources.

Cutting through the static: Client-side communications

The communications code for the client is bundled up nicely in one class, ForumComm. This class, shown in Listing 1, is a communications library that implements client-side networking calls.

import java.net.*;
import java.util.*;
import java.io.*;
import ForumLauncher;
public class ForumComm {
  // port for server to listen for Forum clients
  static final int FORUM_PORT = 5000;
  // possible client requests
  static final int LOAD_ALL_THREADS = 1;
  static final int LOAD_THREAD_ARTICLES = 2;
  static final int POST_ARTICLE = 3;
  ForumLauncher gp;
  public ForumComm (ForumLauncher gparent) {
    gp = gparent;
  }

The top section of the code defines the TCP port used for the Interchange service, as well as the protocol requests that the client can send to the server. These definitions have identical counterpart definitions in the server's ForumConnectionHandler class. The constructor does nothing except provide a pointer to the ForumLauncher applet to allow access to its getCodeBase() method.

Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq

Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq