Important Procedures for an Internet Access Control Application
In the preceding article we started to explore the code that makes up the server communication. If you havenít read that article, please make sure to do so, because almost everything that I will be discussing in this article will directly reference code that we discussed there. A lot of the things that we will be discussing here will make sense once you have read the previous article.
Important Procedures for an Internet Access Control Application - Suggested Improvements (Page 5 of 5 )
If you are going to use this application in an Internet cafť with a large number of workstations, say, 500 or more, I would suggest looking into optimizing the code with critical sections and other functions that deal with bottleneck situations. Also, if you are going to use the application in any other setting (other than an Internet cafe), I would suggest that you create a function to check that all connecting clients have a unique name before registering them. This will avoid confusion on the server's part when communicating with clients.
A further improvement that you can make is to create a function to check whether or not a client is still connected, Iíve avoided this because I wanted to keep the communication between the client and the server to a minimum. Also, the server and client are set up in such a way that, if the client disconnects, the server will immediately detect and confirm it on the server interface. The kind of function Iím referring to is known as a "heartbeat" function or "keep-alives" by communication software developers. It includes placing a timer on the client application that sends a periodic message back to the server to indicate that it is still connected and alive. This is only necessary if you anticipate long hours of inactivity between the server and client. Also, for future changes in the communication format Iíve written a parse function that breaks communication down into four parts. It is based on the current parse() function:
function parse4(s : string; var Token1,Token2,Token3,Token4: string) :
P1,P2,P3 : integer;
P1 := Pos(':',s);
P2 := Pos('@',s);
P3 := Pos(';',s);
//Test if both delimiters are present, in the right order and
//at least 1 char apart
if ((P1 > 0) and (P2 > 0) and (P3 > 0) and (P2 > P1) and (P3 > P2) and (Abs(P3-P2) > 1) and (Abs(P2-P1) > 1))
Token1 := Copy(s,1,P1-1);
Token2 := Copy(s,P1+1,P2-P1-1);
Token3 := Copy(s,P2+1,P3-P2-1);
Token4 := Copy(s,P3+1,Length(s)-P3);
Result := True; //valid string
else Result := False; //invalid string
It is extremely easy to modify this function if you ever need to. Whatís more, you do not have to worry about using common delimiters, because all communication takes place internally between the client and server; no user input is required at all in this case. You would have to worry about delimiters if you want to use the server application as a chat server; then of course you cannot use common delimiters, because users will use common delimiters like ď@Ē if they are sending an email address to someone else on a chat. My current communication protocol would crash if that were to happen.
The next article in the series will deal with the last remaining section of the server application, which is user management. This module will enable the server administrator to add, remove or to view user information.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.