Defining the Interfaces

The first step in creating the system is to lock down the methods that will be used for communication between the server and client components. These interfaces must be created in a separate DLL assembly so that they can be used by both the TalkClient and TalkServer applications. In the sample code, this class library project is called TalkComponent. It contains the following code:

Public Interface ITalkServer

    ' These methods allow users to be registered and unregistered
    ' with the server.
    Sub AddUser(ByVal [alias] As String, ByVal callback As ITalkClient)
    Sub RemoveUser(ByVal [alias] As String)

    ' This returns a collection of user names that are currently logged in.
    Function GetUsers() As ICollection

    ' The client calls this to send a message to the server.
    Sub SendMessage(ByVal senderAlias As String, _
      ByVal recipientAlias As String, ByVal message As String)

End Interface

Public Interface ITalkClient

    ' The server calls this to forward a message to the appropriate client.
    Sub ReceiveMessage(ByVal message As String, ByVal senderAlias As String)

End Interface

' This delegate is primarily for convenience on some server-side code.
Public Delegate Sub ReceiveMessageCallback(ByVal message As String, _
  ByVal senderAlias As String)

ITalkServer defines the basic AddUser() and RemoveUser() methods for registering and unregistering users. It also provides a GetUsers() method that allows peers to retrieve a complete list of online users, and a SendMessage() method that actually routes a message from one peer to another. When SendMessage()is invoked, the server calls the ReceiveMessage() method of the ITalkClient interface to deliver the information to the appropriate peer.

Finally, the ReceiveMessageCallback delegate represents the method signature for the ITalkClient.ReceiveMessage() method. Strictly speaking, this detail isn't required. However, it makes it easier for the server to call the client asynchronously, as you'll see later.

One design decision has already been made in creating the interfaces. The information that's being transferred—the sender's user name and the message text—is represented by separate method parameters. Another approach would be to create a custom serializable Message object, which would be added to the TalkComponent project. Both approaches are perfectly reasonable.

Creating the TraceComponent

In Figure 4-1, both the client and the server are depicted as Windows applications. For the client, this design decision makes sense. For the server, however, it's less appropriate because it makes the design less flexible. For example, it might make more sense to implement the server component as a Windows service instead of a stand-alone application (as demonstrated in the next chapter).

A more loosely coupled option is possible. The server doesn't need to include any user-interface code. Instead, it can output messages to another source, such as the Windows event log. The Talk .NET server will actually output diagnostic messages using tracing code. These messages can then be dealt with in a variety of ways. They can be captured and recorded in a file, sent to an event log, shown in a console window, and so on. In the Talk .NET system, these messages will be caught by a custom trace listener, which will then display the trace messages in aWindows form. This approach is useful, flexible, and simple to code.

In .NET, any class can intercept, trace, and debug messages, provided it inherits from TraceListener in the System.Diagnostics namespace. This abstract class is the basis for DefaultTraceListener (which echoes messages to the Visual Studio .NET debugger), TextWriterTraceListener (which sends messages to a TextWriter or Stream, including a FileStream) and EventLogTraceListener (which records messages in the Windows event log).

All custom trace listeners work by overriding the Write() and WriteLine() methods. The entire process works like this:

1. The program calls a method such as Debug.Write() or Trace.Write().

2. The common language runtime (CLR) iterates through the current collection of debug listeners (Debug.Listeners) or trace listeners (Trace.Listeners).

3. Each time it finds a listener object, it calls its Write() or WriteLine() method with the message.

The solution used in this example creates a generic listener that forwards trace messages to a form, which then handles them appropriately. This arrangement is diagrammed in Figure 4-2.

Figure 4-2: Forwarding trace messages to a form

The following is the outline for a FormTraceListener. This class is implemented in a separate class library project named TraceComponent.

' The form listener is a TraceListener object that
' maps trace messages to an ITraceForm instance, which
' will then display them in a window.
Public Class FormTraceListener
    Inherits TraceListener

    Public TraceForm As ITraceForm

    ' Use the default trace form.
    Public Sub New()
        MyBase.New()
        Me.TraceForm = New SimpleTraceForm()
    End Sub
    ' Use a custom trace form.
    Public Sub New(ByVal traceForm As ITraceForm)
        MyBase.New()

        If Not TypeOf traceForm Is Form Then
            Throw New InvalidCastException( _
              "ITraceForm must be used on a Form instance.")
        End If

        Me.TraceForm = traceForm
    End Sub

    Public Overloads Overrides Sub Write(ByVal value As String)
        TraceForm.LogToForm(value)
    End Sub

    Public Overloads Overrides Sub WriteLine(ByVal message As String)
        ' WriteLine() and Write() are equivalent in this simple example.
        Me.Write(message)

    End Sub

End Class

The FormTraceListener can send messages to any form that implements an ITraceForm interface, as shown here:

' Any custom form can be a "trace form" as long as it
' implements this interface.
Public Interface ITraceForm

    ' Determines how trace messages will be displayed.
    Sub LogToForm(ByVal message As String)

End Interface

Finally, the TraceComponent assembly also includes a sample form that can be used for debugging. It simply displays received messages in a list box and automatically scrolls to the end of the list each time a message is received.

Public Class SimpleTraceForm
    Inherits System.Windows.Forms.Form
    Implements ITraceForm

    ' (Designer code omitted.)
    Public Sub LogToForm(ByVal message As String) Implements ITraceForm.LogToForm
        ' Add the log message.
        lstMessages.Items.Add(message)

        ' Scroll to the bottom of the list.
        lstMessages.SelectedIndex = lstMessages.Items.Count - 1
    End Sub

End Class

This approach is useful for the Talk .NET server, but because it's implemented as a separate component, it can easily be reused in other projects.