User`s guide

Figure 7: VidClient source files
except for acknowledgement messages, which require the first command byte to contain 00, and the
following command bytes to contain the commands received.
The message received is also passed on to the projector, which can be connected on a separate
COM port. This is necessary since the infra-red motion detector is now connected to the computer,
rather than the projector, as was previously the case. After passing on the message to the projector,
VidClient executes the relevant script file using the ShellExecute() MFC function.
A simple internet protocol was developed to transmit the “on” and “off” messages from each
VidClient to VidServer, and to transmit the result of the logical “and” from VidServer to each
VidClient. The protocol is ASCII-based, for easier debugging. VidClient sends one of ONN, OFF or
ERR, depending on whether the state of the infra-red motion detector is on, off, or something else
(this is unlikely, but implemented as part of the protocol as a precaution). VidServer sends back
one of ONN, OFF or MIX, depending on whether the state of both clients was both on, both off, or a
combination. A null byte follows each message, so it can be treated as a string when it is received.
Each message is therefore four bytes.
TCP/IP communication is done using Windows sockets (Winsock). As with MFC, Winsock is
message-based. For example, when a stream socket is created, a message ID number is assigned
to it. A function (in this case, CVidsrvView::OnStreamSrv(), is associated with the ID number,
using the MFC “message map”. The MFC message map is a way to map message ID numbers to
user functions. When a Winsock connection request is received, the CVidsrvView::OnStreamSrv()
member function is automatically called.
14