The Client for an Internet Access Control Application
(Page 1 of 4 )
Recently we finished a series covering the server side for an Internet access control application; now we're ready to take on the client. The client application is what the Internet users will see shortly before a workstation is activated or when a session is completed. It is responsible for both time and user access management as you will see in the rest of the series. Crucially, it is also responsible for processing all communication between itself and the server.
How does it work?
The client application will be running on the workstations and will be activated when these workstations are switched on. At some point in the series of articles, we will be creating a Windows service which will be responsible for activating the client application.
Once the client application is activated, it will automatically try to connect to the server application. If it is successful in doing so, it will send the computer name to the server; if it is not successful in its attempt to connect, a timer will be set to try connecting to the server every minute for as long as the client application is active. While all of the above is going on, the client application will block access to both the keyboard and mouse. Once the client application connects to the server, it will then wait for any requests or commands from the server for processing.
So, when the client application is started, it does the following:
Tries connecting to server every minute.
Blocks keyboard and mouse access.
Reads path to ads and set the path variable.
The server will send one of two communications:
session information – this request contains the time allocated for the session and also the name of the computer for which the session is allocated.
shutdown command – This command essentially shuts down the workstation
Because of the way our communication protocol works, we need to put code into the client application that is capable of handling simultaneous communication. This means that we need to divert client communication away from the main VCL thread. As we’ve already established in the previous articles, the main VCL thread is not thread safe. We therefore need to create a separate thread for client server communication.
The code that we are going to use for this exercise will be exactly the same as that of the server. The only difference will be that we will create an extra thread to continually read any communication from the server. We will call this thread the ReadingThread. It has the following definition:
TReadingThread = class(TThread)
protected
FConn: TIdTCPConnection;
procedure Execute; override;
public
constructor Create(AConn: TIdTCPConnection); reintroduce;
end;
And the following implementation:
constructor TReadingThread.Create(AConn: TIdTCPConnection);
begin
FConn := AConn;
inherited Create(False);
end;
procedure TReadingThread.Execute;
begin
while not Terminated and FConn.Connected do
begin
// refer to my earlier message for this code...
TLog.AddMsg(FConn.IOHandler.ReadLn);
end;
end;
Below is a screen shot of the client application:
The above is a screen shot of what the client looks like at the time of designing. The finished version will not have the buttons or the edit box. Instead, it will fill the entire screen and the ads will dominate most of the screen.
Next: Small and Main Window >>
More Delphi-Kylix Articles
More By David Web
