|
Status: Live Key Technologies: Visual Basic .NET, Windows Communication Foundation (WCF), Microsoft Server 2003, ESX, Oracle, SQL, PL/SQL, IIS Platform: Client-Server, Web GateKeeper is a project that materialized rapidly and had to use a short development cycle. For several decades Georgia Southern Athletics has been trying to find a system that would track student attendance at Athletic events and verify that students had paid their athletic fees. Various solutions have been used over the years but none have performed as intended. Process History Students taking more than 6 hours per semester pay an athletics fee that allows them to gain access to any and all athletic events. Before the current system was put in place, the only requirement for entry was simply the displaying of an Eagle ID card. This method did not validate the Eagle ID nor did it confirm that the student had in fact paid the athletic fee for that semester. In addition, it did not confirm that the student had not already entered once already allowing for students to enter, pass their card back through the fence to a friend, allowing their friend to enter. This allowed for unauthorized entry into the games. Due to a lack of change in Eagle ID Card over several years, many students discovered they could still enter the games whether they were enrolled in classes or not. This included anyone with a Student Eagle ID Card. Alumni, Former Students, and Students enrolled in fewer than 6 hours could show their Student Eagle ID Cards and enter the games. The Process (Pre GateKeeper) The current process incorporates the CS Gold Card System (DIEBOLD) to track whether fees have been paid per semester, validates the Eagle ID Number, checks the Lost Card Code (single digit number), and checks to make sure the student enters the game only once. The Lost card Code is used as a version control for the card that allows for deactivation of a lost card. When a student indicates they have lost their card the LCC is incremented by 1 (0-9 then cycles) deactivating the lost card to protects the students EaglExpress balance and any remaining Dining Plan balances. Tracking this number in the Gate Entry System also ensures that the student is not denied entry to the game because another person has used their lost card to enter the game. The Handhelds required updating before each game to ensure that the offline database was current. A special dining plan (GUS1) was created for athletic events with a balance of 1 (allowing 1 entrance into the game) and updating the offline database ensured that this data was cycled properly so a student would not be denied access to a game based on entrance to another game on a previous date. Upon entrance to the game the Handhelds would deduct 1 Dining Plan balance from the GUS1 Dining Plan indicating that the student had entered the game. This caused issue when more than one event was held on the same day as a student that wanted access to both might find that they were being denied to the second event based on the fact that the GUS1 Dining Plan had already been deducted from their account. The main problem with the system was reliability and tracking. The devices used were MC50 Handhelds with built in WiFi cards and were deployed at each gate. The devices would lose connectivity to the wireless network frequently due to limited receiving capability and the distance from the Wireless Access Points. When the handhelds would disconnect from the network each device would rely on the local offline database to determine eligibility for entry losing the ability to check for a previous entry to that even by the same Eagle ID Number. Students soon discovered that these devices were unreliable and that the system of passing the card to a friend would still work so long as the friend went to a different gate or a different handheld at the same gate. Each time a device would enter offline mode, the software would wait 10-15 seconds before timing out and would give the appearance that the program had frozen frustrating Gatekeepers and students as lines would be delayed by the Handhelds. Once the game was over, each device would be brought back to Auxiliary Services ITS where a technician would download the offline data into the database at which point multiple entries could still be found. The GateKeeper Process (Current Process) GateKeeper was commissioned after the previous solution was found to be ineffective and largely defunct. The previous software had major flaws and the hardware the software ran on was extremely limiting proving to be more detrimental to the success of the previous software than the software itself. The major pitfalls found in the previous software were heavily considered in the design stages and great care was taken to eradicate each issue as much as technically possible. A brief overview of technical considerations based upon prior software failures: • Offline Mode time out was reduced to 2.5 seconds (this may be reduced further after live data is analyzed.) • The platform was changed from Handhelds to Netbooks with more reliable WiFi receivers. • The Handhelds used in the previous solution were included with the final solution but have been pushed as an auxiliary device to the Netbooks. • Entrances are now tracked per event and are not based on a Dining Plan balance. • Re-entrance attempts are not only blocked but are tracked and will provide metric data as to the number of re-entrance attempts the solution did not allow. • The offline data upload occurs immediately upon reconnection to the server and not days later when a technician uploads the data.
A great amount of consideration went into the system in regards to future metric and analytic data in related to event attendance that can be explored once the system is fully operational. Swapping the platform to Netbooks allows for greater reliability and performance as well as allowing us to present the photo of the student to the gatekeeper for further authentication of the student’s identity. Taking advantage of multi-threading technology has allowed us to allow the devices to upload any offline transactions in the background as soon as the device enters online mode. This will ensure that any momentary connectivity issues do not allow multiple entries based upon missing online data. This data exchange is asynchronous meaning that online transactions will not be downloaded per device to update their online database. Refer to case examples below for further explanation. The communications are currently asynchronous due to the layer of complexity and application overhead this would generate. At this time the consensus is that the effort required to include this capability could be better spent elsewhere. 1. Student A enters Gate 1 with a Netbook that is in Online mode. Student A then passes their card to Student B. Student B proceeds to Gate 2 and attempts to enter Gate 2 with a Netbook that is online. RESULT: Entry Denied 2. Student A enters Gate 1 with a Netbook that is in Online mode. Student A then passes their card to Student B. Student B proceeds to Gate 2 and attempts to enter Gate 2 with a Netbook that is Offline. RESULT: Entry Approved – Duplicate Entry Recorded 3. Student A enters Gate 1 with a Netbook that is in Offline Mode. The Netbook enters Online Mode. Student A then passes their card to Student B. Student B proceeds to Gate 2 and attempts to enter Gate 2 with a Netbook that is Online. RESULT: Entry Denied- Duplicate Entry Attempt Recorded 4. Student A enters Gate 1 with a Netbook that is in Offline Mode. The Netbook enters Online Mode. Student A then passes their card to Student B. Student B proceeds to Gate 2 and attempts to enter Gate 2 with a Netbook that is Offline. RESULT: Entry Approved- Duplicate Entry Recorded
Using the asynchronous communication model leaves us with case 1 and case 3 being favorable to the system. Implementing synchronous communications would expand favorable cases to include a large percentage of case 2 and case 4 with re-entrance attempts being stopped. GateKeeper Architecture When designing the system a major consideration was security of the transactions. A custom security class was written to use a rotating encryption password. In addition to the rotating password, each device communicates with the server using a different rotating password so no two devices communicate using the same encryption. If the encryption is compromised for a single device, every other device on the system will still be secured. The encryption we used is 256-bit AES encryption on the message layer. The server side counterpart to GateKeeper has been named the KeyMaster. All communications by GateKeeper will be directed to KeyMaster and KeyMaster will handle all database transactions. This ensures that database passwords are not being sent out over the wireless signals and allows for further filtering of allowable devices. Devices that will be used by GateKeeper will have to be registered in the server before KeyMaster will allow communications between the devices. GateKeeper was written in VB.Net for the explicit purpose of ease of transitioning from one programmer to another. VB.Net is one of the easiest languages to learn and is highly used in many industries. This also allowed us to use one language to write both the Handheld application and the Netbook application. The KeyMaster Service is also written in VB.Net. GateKeeper incorporates the Windows Communication Foundation for communications between server and client. The KeyMaster service is installed as a Windows Service and can run on any version of windows. The current server environment is hosted one two separate ESX hosts in the Auxiliary ESX environment. We have cloned the original server and configured load balancing. The virtual server is configured to see 4 processors at 2.7 Ghz each bringing the server processing power to 10.8 Ghz per virtual machine with the total processing power to 21.6 Ghz for both machines. During events the average processor usage rarely climbs above 1.5 Ghz per virtual machine. Administrative functions will be handled the GateKeeper Web Console that is hosted on the Auxiliary Services Web Server GSUAUXAS. The development of this piece of GateKeeper was done in PHP, which is currently one of the most widely used web development languages, in a modular manner allowing for easy upgrade and maintenance. |
