User`s guide

This function handles connection requests, and decides whether to accept a connection or not.
The algorithm used here is straightforward. Two pointers are previously assigned to nil, but are
assigned to stream sockets if a connection already exists. If either of the two pointers is nil, then
the connection is accepted, and assigned to the (previously nil) pointer. If both are assigned non-nil
values, then the connection is refused.
The values of these two pointers are kept up to date. If a connection closes, or a connection error
occurs, the offending socket is closed down and assigned nil. This way, connections can be closed
and opened at any time, and the server will adjust to reflect the current connection state.
However, there is one exception. If a client process dies without its connection being closed (e.g.
the client computer crashes, or the connection is physically broken and cannot be reconnected), then
the server will remain “connected” to that client. The socket pointer will not be assigned nil, and
the server will assume that the connection still exists.
This is a problem that exists with many IP applications. Unless a server application regularly
polls its clients, this type of disconnection cannot be detected. However, there is a relatively simple
solution if this occurs to VidServer — quitting and relaunching the server and then the client
applications. This forces the old connections to be closed and reopened.
VidServer handles all its Winsock communication asynchronously. This means that it can send
and receive data simultaneously. When VidServer sends data through a stream socket, it actually
just initiates the send. The transfer takes place in the background. This leaves VidServer to continue
its other tasks, such as receiving data from one of its clients.
TCP/IP communication is achieved using the CWinsock class. This class was provided as part of
the Visual C++ package. The serial port communication class (CSerial) was originally taken from
public domain source code, but has been heavily modified to allow greater customisation required
by VidClient. VidServer does no serial port communication.
VidServer and VidClient both read settings stored in external text files, named “server.prf” and
“client.prf” respectively. They must be located in the same directory as the application itself. The
“.prf” extension is a contraction of the word “preferences”. Each preference file contains different
settings. The files are text files, with one line for each setting. The “server.prf” file just contains
settings for the listening TCP/IP port. The “client.prf” file contains settings for the server TCP/IP
port, the COM port name and baud rate for the infra-red detector, the COM port name and baud
rate for the projector connection, and the paths to the “up link” and “down link” script files. If a
preference file cannot be found or opened, default settings are used, which are hardcoded into each
application. However, the file must conform to the structure given, otherwise the settings will not
be read correctly, causing unpredictable results.
Upon launching VidServer, the user is presented with a window (see Figure 8). The window
contains a list displaying the current status of the server. Each line represents a separate event,
and each event is timestamped. Events include Winsock initialisation, server port creation, client
acceptation and connection, receiving and sending data, the current state of the two connections,
and any errors that occur.
VidClient must be launched after launching VidServer, so that it can establish a connection with
VidServer. Upon launching VidClient, the user is presented with a dialog box requesting the user
to enter the host name or IP address of the server they wish to connect to (see Figure 9). After
connecting to the server, a window is displayed, similar to the VidServer window (see Figure 10).
As with VidServer, this window contains a list containing a record of timestamped events. Events
include Winsock initialisation, socket stream creation and connection to the server, receiving and
15