30.0 Client-Server System Standards 

A Client-Server System (CSS) can be fragmentally defined as a Server-Based Game System (SBGS), a Server-Supported Game System (SSGS) or a hybrid of the two, all of which can be defined as the combination of a Central Server, Client Terminals and all Interface Elements that function collectively for the purpose of linking the client terminal with the Central Server to perform a myriad of functions related to gaming, which may include, but are not limited to:

(a) Downloading of Game Logic to the Client Terminals;
(b) Central Server Random Number Generation;
(c) Thin Client Gaming Configurations.

The communication network may be totally contained within a single venue (LAN) or over a wide area network (WAN) whereby a server in one location supports client terminals in multiple sites. 

30.1 Server-Based Game System (SBGS) Defined
SBGS is the combination of a server and client terminals in which the entire or integral portion of game content resides on the server.  This system works collectively in a fashion in which the client terminal will not be capable of functioning when disconnected from the system. 

30.2 Server-Supported Game System (SSGS) Defined
SSGS is the combination of a server and client terminal(s) which together allow the transfer of the entire control program and game content to the client terminal(s) for the purpose of downloading control programs and other software resources to the client terminal on an intermittent basis.  The client terminals connected to the system are capable of operating independently from the system once the downloading process has been completed.  This configuration encompasses cases where the system may take control of peripheral devices or associated equipment typically considered part of a conventional client terminal such as a bill validator or a printer.  In a System Supported Game, game outcome is determined by the client terminals connected to the system and not by the system itself.  The client terminal is capable of functioning if disconnected from the system. 

30.3 Communication Protocol.
Each component of a CSS must function as indicated by the communication protocol implemented.  All protocols must use communication techniques that have proper error detection and/or recovery mechanisms, which are designed to prevent tempering.  Information related, game outcome, financial transactions, and game recall information must be encrypted by a means approved by the Commission. 

30.4 Loss of Communication
For a Server-Based Game System (SBGS), a client must be rendered unplayable if communication from the server or system portion of the client terminal is lost.  If a game is in progress either the client terminal must have the capability to complete the game including accurate accounts of all records of the game or a mechanism must be provided to recover to the point of the game when communication was lost.

Alternatively, in a multi-player environment, a loss of communication can result in aborting the game and refunding player’s wagers.

In the case of Client Terminals that have lost communication with the server, the CSS must provide a means, such as a hand pay, for patrons to cash out credits indicated on the Server-based client terminal at the time communication was lost. 

30.5 System Security
In the event the CSS Server is utilized in conjunction with other networks; all communication, including Remote Access, must pass through at least one approved application-level firewall and must not have a facility that allows for an alternate network path.  If an alternate network path exists for redundancy purposes, it must also pass through at least one application-level firewall.

30.6 Firewall Audit Logs
The firewall application must maintain an audit log of the following information and must disable all communication and generate an error event if the audit log becomes full:

(a)  All changes to configuration of the firewall;
(b) All successful and unsuccessful connection attempts through the firewall; and
(c) The source and destination IP Addresses, Port Numbers and MAC  Addresses.

30.7 Remote Access
Remote Access is defined as any access to the system outside of the ‘Trusted’ Network.  Remote Access, where permitted, shall authenticate all computer systems based on the authorized settings of the CSS or firewall application that establishes a connection with the CSS. 
The security of Remote Access will be reviewed on a case-by-case basis, in conjunction with the current technology and approval from the Commission.  The following are additional requirements:

(a) No unauthorized remote user administration functionality (adding users, changing permissions, etc.);
(b) No unauthorized access to any database other than information retrieval using existing functions; and
(c) No unauthorized access to the operating system.

30.8 Remote Access Auditing
The CSS Server must maintain an activity log either automatically or have the ability to manually enter the logs depicting all Remote Access information that includes:

(a) The Log on Name;
(b) Time and date the connection was made;
(c) Duration of connection; and
(d) Activity while logged in, including the specific areas accessed and changes that were made.

30.9 Wide Area Network Communication
Wide Area Network (WAN) communication within the CSS is permitted provided that the following criteria is met:

(a) The communication over the WAN are secured from intrusion, interference and eavesdropping via techniques such as use of a Virtual Private Network (VPN), encryption, authentication etc; and
(b) Only functions documented in the communication protocol are used over the   WAN.  The protocol shall be provided to a third party testing laboratory and the commission for evaluation.  The protocol documentation may be in multiple parts e.g. delivery mechanism and message formats, etc.

30.10 CSS Server Requirements
This section covers the elements common to the “back of the house” operations of a CSS.  The Game Server(s) may be located locally, within a single facility or may be remotely located outside of the facility such as over a Wide Area Network (WAN).  In the case where a CSS Server also performs tasks as required by other systems, (i.e. On-Line Monitoring and Control System, Ticket Validation System, etc) those portions would have to be evaluated against the appropriate Arkansas regulation.  

30.11  Multiple Servers
A CSS  may in fact be a collection of servers for load balancing, redundancy or functionality reasons.  For example, there might be two or more game servers, a finance server, monitoring server, download server, etc.  The system as a whole, which may be a collection of such servers, must meet the full requirements of this specification but not necessarily each server. 

30.12  Operation and Server Security
For a Server-Based Game System and hybrid systems as applicable, the Game Server shall generate and transmit to the Client Terminals; control, configuration and information data, depending upon the actual implementation.  Examples include: credit movement, random numbers, game result components (e.g. balls, cards or reel stop positions), actual game results or updates to the credit meter for winning games.

For a System-Supported Game System and hybrid systems as applicable, the Game Server will not participate in the game determination process i.e. the primary functions will be that of downloading control programs and other software resources, or providing command and control instruction that may change the configuration of the software already loaded on the client terminal, on an intermittent basis. 

30.13  Intrusion Protection
All servers shall have sufficient physical/logical intrusion protection against unauthorized access.

30.14  Configuration Access Requirements
The CSS interface element setup/configuration menu(s) must not be available unless using an authorized access method that is secure. 

30.15  Server Programming
There shall be no means available for an Operator to conduct programming on the server in any configuration (e.g. the Operator should not be able to perform SQL statements to modify the database).  However, it is acceptable for a Network Administrator to perform authorized network infrastructure maintenance with the sufficient access rights that would include the use of SQL statements that were already resident on the system. 

30.16  Virus Protection
It is recommended all servers and client devices should have adequate virus protection. 

30.17  Copy Protection
Copy protection to prevent unauthorized proliferation or modification of software, for servers or clients, may be implemented provided that the method of copy protection is fully documented and provided to a third party independent test laboratory and the commission, who will verify that the protection works as described. 

30.18  System Failure
The CSS shall be designed to protect the integrity of pertinent data in the event of a failure.  Audit logs, system databases, and any other pertinent data must be stored using reasonable protection methods.  If hard disk drives are used as storage media, data integrity must be assured in the event of a disk failure.  Acceptable methods include, but are not limited to, multiple hard drives in an acceptable RAID configuration, or mirroring data over two or more hard drives.  The method used must also provide open support for backups and restoration.  Backup scheme implementation must occur at least once every day, although all methods will be reviewed on a case-by-case basis by the commission. 

30.19  Recovery Requirements
In the event of a catastrophic failure where the CSS cannot be restarted in any other way, it shall be possible to reload the database from the last viable backup point.  This must fully recover the contents of that backup and shall consist of at least the Significant events, Auditing information and Specific site information such as game configuration, security accounts, etc.

30.20  Self Monitoring
The CSS must implement self-monitoring of all critical Interface Elements (e.g. Central hosts, network devices, firewalls, links to third parties, etc.) and shall have the ability to effectively notify the system administrator of the condition, provided the condition is not catastrophic.

The CSS shall be able to perform this operation with a frequency of at least once in every 24-hour period.  The implementation of self-monitoring schemes will be reviewed on a case-by-case basis by the commission and the test laboratory.  Additionally, all critical interface elements will be reviewed on a case per case basis and may require further action by the system depending upon the severity of the failure. 

30.21  CSS Software Verification
Each integral component of the CSS must have a method to be verified via a “third-party” verification procedure. 

The Client Terminal and/or the applicable Server Side critical Game components shall provide the ability to conduct an independent integrity check of the control programs, from a third-party outside source.  The verification program used for the integrity check may be embedded within the game software or have an interface port that is used to authenticate the media with the verification program.

The third-party verification process must not include any process or security software provided by the gaming manufacturer. 

30.22  Verification of Devices That Cannot Be Interrogated
Program devices that cannot be interrogated, such as Smart cards, may be used provided they are able to be verified by the following methodology:

(a) A challenge is sent by the peer device, such as a hashing seed, to which the device must respond with a checksum of its entire program space using the challenge value.
(b) The challenge mechanism and means of loading the software into the device is verified by an independent testing laboratory and approved by the Commission. 

30.23  Server Recall Requirements
The Server that supports a Server-Based Game must be able to provide the following game history information.  In the case of a hybrid system it is allowable for this information to be stored either on the server or at the client terminal as long as all information is accounted for. 

(a) A complete play history for at least the last ten (1) games for each client station connected to the Server-Based game.  The last play information shall provide all information required to fully reconstruct the last ten (10) plays.
(b) All Values shall be displayed including the initial credits available, credits bet, credits won, and credits paid.  If a progressive was awarded it is sufficient to indicate the progressive was awarded and not display the value.
(c) Play history shall include the final game outcome including all player choices and any bonus features offered, the results of Double-Up (if applicable) and reflect position dependent events if the outcome results in an award. 
(d) Play history shall reflect bonus features in their entirety.  If a bonus round lasts for x number of events each with separate outcomes, each of the x number of events shall be displayed with its corresponding outcome.  For games that may have infinite free games there shall be a minimum of fifty (50) games recallable in the play history. 
(e) If the play history is stored on the Server the capability to initiate game recall must be available at the client for recall information specifically associated with the particular client station initiating the game recall.
(f) The capacity to initiate game recall for any and all clients that make up the Server-Based Gaming System must be available from the system or server portion of the SBGS.  The requirement to display game recall applies to all game programs currently installed on the server portion of the Server-Based Game.  If the system is hybrid then the game results shall be available from the server for all clients that make up the SBGS in report form as long as play history details as stated are available on the client terminal. 
(g) A complete transaction history for transactions with a cashless wagering system to include the most recent and the previous thirty-four transactions prior to the most recent transaction for each client station that incremented any of the cashless in-or out meters.  The capability to initiate transaction history must be available at the client terminal for the transaction history specifically associated with the particular client terminated initiating the history information request. 

30.24  Download Data Library
The Download Data Library refers to the formal storage of all approved data files that may be downloaded to Client Terminals including control and game software, peripheral firmware, configuration data, etc. 

30.25  Update of Download Data Library
Where applicable, the CSS Download Data Library shall only be written to, with secure access that is controlled by the commission, in which case the manufacturer and/or operator will be able to access the Download Data Library, provided that this access does not permit adding or deleting Download Data Files; or the Download Data Library shall only be written to using a method that is acceptable by an independent test laboratory and the commission. 

30.26  Download Data Library Audit Log
Any changes that are made to the Download Data Library, including the addition, changing or deletion of Game Programs, must be stored in an un-alterable audit log, which shall include:

(a) Time and Date of the access and/or event;
(b) Log In Name and Download Data Files added, changed, or deleted.

30.27  Download Activity Audit Log
Any record of activity between the Server and the Client that involves the downloading of program logic, the adjustment of client settings/configurations, or the activation of previously downloaded program logic, must be stored in an unalterable audit log.  This log shall include the Client Terminal(s) which the Game Program was downloaded to and, if applicable, the program it replaced.  In addition the log shall include the Client Terminal(s) which the Game Program was activated on, the program it replaced and Changes to the Client Terminal configuration settings/configurations and what the changes were. 

30.28  Download of Client Terminal Data Files and Control Programs
This will outline the requirements of the CSS when downloading software, games and other configuration data to Client Terminals, if the Server provides the functionality of downloading control programs and other software resources, whether for a Server-Based Game System, a System Supported Game System or a hybrid system. 

30.29  Authentication of Control Programs
The CSS shall authenticate all critical files including, but not limited to, executables, data, and other files, which may affect the game outcome or the compliant operation of the CSS during the following:

(a) Any processor reset; (power-up, soft reset)
(b) The first time the files are loaded for use. (even if only partially loaded)

The CSS shall employ an industry standard secure hashing algorithm (e.g. MD-5 or SHA-1).

In the event of failed authentication the player terminal should immediately enter an Error Condition with the appropriate audio and visual indicator.  This Error shall require operator intervention.

The CSS shall display specific error information and shall not clear until either the file authenticates properly, following the operator intervention, or the medium is replaced or corrected, and the memory is cleared (if applicable), the component is restarted, and all files authenticate correctly.

30.30  Control Program
These minimum technical regulations shall be met, where applicable, when downloading/activating control programs from the CSS Server to the Client Terminal.

(a) The Client Terminal and/or the CSS Server must have a method to monitor and report to the MCS all external door access during a foreground program download and/or activation process.  If the CSS does not have the ability to monitor the door access during the foreground program download and/or activation process, an independent test laboratory’s report shall indicate as such so that Internal Controls can be developed to ensure the security of the Client Terminal’s security, primarily with regard to the cash compartments, where applicable.

(b) Below are the methods to store the current game data that is pertinent to the individual Client Terminal when updating the Control Program in an SSGS configuration;

i. Where applicable, the Game Data is uploaded and security stored on the CSS Server and is maintained for a minimum of 24-hours and archived after that time; or is maintained in log or script file.  If this method is used, the process in downloading the new Control Program to the Client Terminal must ensure that all critical areas of memory are overwritten by a default value; or
 ii. The Game data is maintained at the client terminal; or
iii. If the CSS is not capable of meeting the above regulation, Regulatory Control may be required on the CSS Server for new Client Terminal Control Program downloads.  In addition, the alternate methods used will be reviewed by an independent test laboratory and the commission on a case-by-case basis.

30.31 Control of Client Terminal Configurations
Client Terminals used in a CSS environment that have alterable configurations that require Regulatory Control, as outlined within Arkansas EGS regulations, may be waived provided that the rules within this section are met.

30.32 Paytable/Denomination Configuration Changes
Client Terminal Control Programs that offer multiple paytables and/or denominations that can be configured via the CSS Server will not require Regulatory Control to change the paytable selected, provided the following rules be met.

(a) All paytables that are available meet the theoretical payback percentage and odds requirements as stated in Arkansas EGS regulations.
(b) The client terminal and/or CSS Server maintains the Amounts Bet and Amounts Won meters within Critical Memory for each of the paytables that are available.
(c) The Client Terminal maintains the Master Accounting meters in dollars and cents or the lowest denomination available for the local currency. 
(d) The game is in an Idle State when the update occurs.
(e) The change will not cause inaccurate crediting or payment (i.e., games using coin hoppers and coin acceptors with a fixed denomination).

30.33 Client Terminal Critical Memory Clear
The process of clearing memory on the Client Terminals via the CSS must utilize a secure method that would require Regulatory Control.  For systems that do not comply with this rule, the commission must approve the method used.

30.34 Random Number Generator
A CSS may be utilized for the generation of Random Values, which are subsequently communicated to the Client Terminal’s Control Program that is required for the determination of game outcomes.  The CSS Server generation of Random Values shall not include the generation of finite pools of game outcomes.  In the event the CSS has the ability to download Random Values to the Client Terminal, the Random Number Generator shall function in accordance with the Randomness Requirements as outlined in the Arkansas EGS regulation.

Systems utilizing finite pools of game outcomes (i.e. Electronic Pull-Tab Systems) shall dispense upon request from a Client Terminal an Electronic Ticket or Game Outcome.  All finite games must be played without replacement.  Once dispensed such ticket or outcome must not be reused until the Game Set is replenished. 

The system shall utilize randomizing procedures in the creation of the Game Sets for Electronic Tickets or Game Outcomes.  The randomizing procedure shall be in accordance with the RNG requirements stated in the Arkansas EGS regulation with the exception of mechanical based RNG games. 

30.35 CSS Client Terminal
This terminal is used by the player to place wagers, play the game(s) on offer and win prizes (when applicable).  The Player Terminal may receive game play information from the Game Server, in the case of System Based Game System (SBGS) or make it own determination in the case of a System Supported Game System (SSGS), and then displays the information to the player.  Game play and other functionality may be separated in parts, where some components may be generated within or outside the Player Terminal (e.g., Player Terminals that function with a system).  A client terminal shall be robust enough to resist forced illegal entry unless such entry causes an error condition, and which does not affect the subsequent play or any other play, prize or aspect of the game.

30.36 Software Activation
Prior to execution of updated software, the Client Terminal must be in an Idle State for a time fame determined by the Commission and the software is successfully authenticated, as defined within Arkansas regulation.