If you’ve ever visited an Internet café, you've noticed that there is usually a timer on the screen that tells you how much time you have left to use the Internet. In this series of articles we will discuss both the underlying architecture of such an application as well as the code involved, culminating in creating an example application.
Building an Internet Access Control Application (Page 1 of 4 )
We will write this application using Borland Delphi 7 and Indy version 10.1.5, because it has the Internet components that we require. Let’s define some terms that we will be using throughout this article series:
Workstation – refers to all computers on a network that are not servers.
Server – a computer that serves and/or controls workstations.
Client application – computer program that runs on a workstation whose main job is to “talk” to the server application.
Server application – computer program that runs on the server who main purpose is to respond to requests made by the client application.
Session – refers to the time allocated to a client. Currently the times are 15, 30 and 60 minutes.
What are the overall requirements?
Let’s look at some of the requirements for such an application.
It must clearly show the time allocated for the session.
It must clearly show the time left for that particular session.
The application MUST have an authentication section. We need to know who or which staff member allocates Internet access to users on a given day.
A login/logout facility should be provided, to handle the above requirement.
Users of our Internet café will not need to enter any code or login details. All access to workstations must be centrally controlled.
When staff members allocate a workstation, the end time of the session must be shown on the application.
Based on the above requirements, as well as the structure of the computers in an Internet café, we can conclude the following:
The application will operate using the client/server model. This means that there will be a server application that will have control over a client application which is installed on the workstations.
The server application will have the ability to lock or open a workstation.
All client applications must "register" with the server application when it is first switched on. This will be achieved by a service application that will periodically check to see if the client application is running.
The server must keep a list of workstations that are available for Internet access, using keywords such as "busy" or "free" so staff can easily identify and allocate Internet sessions.
We already know that our application requires using the client server architecture. To implement our application's requirement, we need to create a custom protocol for this application to work:
This protocol will give the client and server applications the means to "talk" to each other. In addition to the client and server applications, we will also need to create a service application for the Internet access application. It will have two functions: first, it will be responsible for starting up the client application; and second, it must check every couple of minutes to see if the client application is running, and if not, it must start it up. When a workstation is first switched on, the client application should start automatically at start up (this will be the job for the service application).