High level design (HLD) Remote slots project

Prepared for: TBD

Prepared by:

SoftWeave- Software integration solutions

Revision
1

Date
24/10/2012

Author

Description
First release

SoftWeave Ltd.

template High Level Design

Introduction ................................................................................................................. 5 1.1 Background .......................................................................................................... 5 1.2 Design Goals ........................................................................................................ 5 2 Architecture................................................................................................................. 6 2.1 Introduction .......................................................................................................... 6 2.2 Major components ................................................................................................ 6 2.2.1 Physical Diagram .......................................................................................... 7 2.2.2 Users ............................................................................................................. 7 2.2.2.1 End user ................................................................................................. 7 2.2.2.2 Operator ................................................................................................. 7 2.2.2.3 Support Teams ....................................................................................... 7 2.2.3 Video ............................................................................................................. 9 2.2.4 Slot Machine Take Over ............................................................................... 9 2.2.5 CDN Services.............................................................................................. 10 2.2.6 Slot Management BO (EX) ......................................................................... 10 2.2.7 Chat server .................................................................................................. 11 2.2.8 Application servers ..................................................................................... 11 2.2.9 OLTP DB Server......................................................................................... 11 2.2.10 Reporting BO Server................................................................................... 12 2.2.11 Monitoring log ............................................................................................ 12 2.2.12 SAN............................................................................................................. 12 2.3 System components (logical) ............................................................................. 13 2.3.1 Operator ...................................................................................................... 13 2.3.2 Presentation Layer ...................................................................................... 14 2.3.2.1 Cashing\Front ...................................................................................... 14 2.3.2.2 Lobby ................................................................................................... 14 2.3.2.3 Game client .......................................................................................... 15 2.3.3 Integration Server........................................................................................ 16 2.3.3.1 User management ................................................................................ 16 2.3.3.2 Transaction management ..................................................................... 16 2.3.4 Gaming platform ......................................................................................... 16 2.3.4.1 Slot management ................................................................................. 16 2.3.4.2 Hostess MNG ...................................................................................... 17 2.3.5 Gaming DB ................................................................................................. 17 2.3.5.1 Dictionary Schema .............................................................................. 18
2

template High Level Design

2.3.5.2 Configuration Schema ......................................................................... 18 2.3.5.3 User Base ............................................................................................. 18 2.3.5.4 Gaming DB .......................................................................................... 19 2.3.5.5 Gaming Control ................................................................................... 19 2.3.6 Reporting..................................................................................................... 19 2.3.6.1 Reporting APP ..................................................................................... 19 2.3.6.2 Reporting DBs ..................................................................................... 20 2.3.6.3 Reporting DWH ................................................................................... 20 2.3.7 Slot Management BO (EX) ......................................................................... 20 2.3.7.1 Data Assimilation ................................................................................ 20 2.3.7.2 Pit manager .......................................................................................... 20 2.3.7.3 Reports and Analytics .......................................................................... 20 2.3.8 Video ........................................................................................................... 21 2.3.9 Slot machine take over ................................................................................ 21 2.3.9.1 Microcontroller .................................................................................... 21 2.3.10 Server Side .................................................................................................. 22 2.3.11 Monitoring logging ..................................................................................... 22 3 System main functionalities ...................................................................................... 23 3.1 Game play .......................................................................................................... 23 3.1.1 General ........................................................................................................ 23 3.1.2 Flow diagram .............................................................................................. 24 3.1.3 Error handling/messages ............................................................................. 25 3.2 Join Hostess ........................................................................................................ 25 3.3 Join Hostess ........................................................................................................ 25 3.3.1 General ........................................................................................................ 25 3.3.2 Flow diagram .............................................................................................. 26 3.3.3 Error handling/messages ............................................................................. 26 3.4 History ................................................................................................................ 27 3.4.1 Flow diagram .............................................................................................. 27 3.4.1 Error handling/messages ............................................................................. 27 3.5 Slot Queue .......................................................................................................... 28 3.5.1 Flow diagram .............................................................................................. 28 3.5.2 Error handling/messages ............................................................................. 28 4 Hardware components in the system ........................................................................ 29 4.1 General ............................................................................................................... 29 4.1.1 Application server ....................................................................................... 29

template High Level Design

4.1.2 SAN............................................................................................................. 30 4.1.3 Machine control node ................................................................................. 30 4.1.3.1 General................................................................................................. 30 4.1.3.2 Set up and Configuration ..................................................................... 30 4.1.4 DB ............................................................................................................... 30 4.1.4.1 General................................................................................................. 31 4.1.4.2 Set up and Configuration ..................................................................... 31 4.1.5 Cameras....................................................................................................... 31 4.1.5.1 General................................................................................................. 31 4.1.5.2 Set up and Configuration ..................................................................... 31 5 Performance (load model)......................................................................................... 32 6 Miscellanea / Appendices ......................................................................................... 33 6.1 Interoperability with other systems .................................................................... 33 6.1.1 Chat server .................................................................................................. 33 6.1.1 External BO system .................................................................................... 33 6.1.2 Video streaming and control ....................................................................... 33 6.1.3 CDN services .............................................................................................. 33 6.1.4 Operator ...................................................................................................... 33 6.1.5 Monitoring .................................................................................................. 33 6.2 Expandability ..................................................................................................... 33 6.3 Monitoring .......................................................................................................... 33 6.4 Security............................................................................................................... 34 6.5 Open Issues ........................................................................................................ 34

template High Level Design

1 Introduction
1.1 Background
This design document describes the structure of the new online gaming product. The system will allow players to activate and place bets on actual physical video slots in remote. The system will support supporting and premium services such as privet hostesses and real time touring of the casino floor.

1.2 Design Goals

The design aims to outline the physical and logical structure and flows of the system based on the functionalities as defined in the business requirements document. The document also refers to the external integrated systems listing major requirements and pre conditions for a successful integration. The backend architecture of the system will be structured using standalone modules. The modules will be constructed to separate functionalities to allow scalability and flexibility. This flexibility will allow the system to support multiple integrations.

template High Level Design

2 Architecture
2.1 Introduction
The remote slot application aim is to provide the end user a live video slot play experience.It will contain a combination of software and hardware components controlling the game flow. The application will integrate several existing components alongside proprietary modules in to one eco system. A dedicated video slot floor will be set up with the capabilities of setting up to 500 slot machine and support for video equipment lightning and adequate walking space and staging location for live hostess. To allow remote physical control on the slot machines the solution will require installing microcontrollers to mimic the click operations of the end user, extensive wiring, video equipment and hardware. All of the above should be hidden from the end user to allow an authentic video slot floor look and feel. The slot machines will be fitted in customized cabinets that will hide the wiring and microcontrollers. The rest of the hardware will be located in the servers room, and there will be an additional room for the NOC and floor management stuff. The application is a client server distributed application with several components located outside the casino premises.

2.2 Major components

template High Level Design

2.2.1 Physical Diagram

2.2.2 Users

2.2.2.1 End user

These are the casino players. First version will be developed to support HTML 5. Although the logical front end of the application will allow quick integration with any presentation layer. The finalversion will support multiple platforms from desktops to mobile phones, each platform will undergo user interface customization to allow support to special platform limitation and features (such as touch screens limited presentation space).

2.2.2.2 Operator
The casino is a white labelsolutionbuilt to support multiple operators. The operator is responsible to bring the end user in to the casino and manage their bankroll. An operator will use our integration API to connect to the casino and initiate game play. Using a web based reporting system interface the operator will be able to view his and only his client game play and general revenue reports.

2.2.2.3 Support Teams

The support teams are the casino in house employs responsible to the day to day operation, and are built from three major groups:

template High Level Design

2.2.2.3.1 Pit manager

The pit manger manages the day to day activity of the casino. He selects the slot machines to present in the casino lobby, monitors game results and solve conflicts (slot machine play stuck ) . Hostess management ( see section below ) The operator will work using a desktop\laptop with rich client GUI (TBD WPF,Flash, Java ) . The interface will provide him data from all the physical components of the application from the video feed of the certain slot or hostess to the external BO reports.

2.2.2.3.2 Hostess
The hostesses will fill role of the entertainment provider in the casino. Once an end user connects to the hostess his basic data will be displayed on the hostess client, this information will include name nickname, language and VIP level. . Hostesss availability list will be filtered per user based on his characteristics (language) and history connections. The hostess application will hold a rich client that will provide direct video conference between the hostesses and the end user private and public chat options. That client will establish connection with the chat server video streaming system gaming platform ( for user data and availability ) The hostesses client will support two major formats Touring hostesses with the neck mike, portable camera and tablet, communicating by public chat rooms and answer via voice. Privet hostess entertaining the client while playing a slot machine the machine will be equipped with a camera, microphone, headset and a screen to display the clients name and text chat. Her hand need to be free.

2.2.2.3.3 Support
The support group cover several functions all connected to back office services: NOC first response team that monitors the casino activity unlike the Pit Manager they will not manipulate the actual slot machines. The NOC team will receive inputs from the logging application (fed by the application servers and microcontrollers), floor hardware log reporting, reporting application aggregating results and the external BO application. Once an error is noticed will attempt to address the issue!if not in their jurisdiction will escalate! Second level support second level support is targeted to answer the operator issues. End users issues will be dealt through their operator representatives. The team members will enjoy rich client interface with access to player\operator history, statistical and operational reports.

template High Level Design

2.2.3 Video
The physical layer enabling communication between the live casino floor (hostess and slot machines ) to the end user. The system is comprised mostly of IP cameras( which are cameras that transmit the image over the Ethernet). The cameras feed will be streamed directly to the end user, some of the premium cameras (provided with augmented reality ) might be connected to a PC that will manage and relay their stream to the network . All cameras will be monitored and accessed via the network. The cameras will stream four types ofcontent groups. Setup options will be a selected according to the required functionality : o General video of the casino floor for ambiance o Single slot machine game play image o Slot machine supporting Private hostess - the video feed will be served in an enhanced fashion , it will be augmented with extra visual and 3d graphical effects o Touring hostess supporting walk about features for hostesswhile touring the casino floor. The major inputs and outputs will be: o a non-processed video stream o processed video stream that will contain an overlay of augmented reality , graphics etc' o audio from the hostess wearable mics The video system will have a management server that will connect between the cameras streams to end user, in case a few clients are watching the same slot machine they will be served the same stream. The management server will also monitor and check the availability of the camera and will provide alerts in the case of a malfunction. Management server will run on JBOSS using java and java web services technologies

2.2.4 Slot Machine Take Over

The takeover system will comprised of main server group that will manage and control embedded microcontroller nodes over TCP/IP channels.

template High Level Design

It is estimated that we shall need 3-5 servers one for every 100-160 machines the server will need to process hundreds of command in parallel and hold hundreds of TCP/IP connections. The nodes will be comprised out of microcontroller and peripheral electronic to interface and control the machine electro mechanical interface. The microsystem client will be programmed via dedicated language according to the chosen microcontroller (C, C like languages). System management will be carried using a web based GUI that will report the status of the system and will enable management functionality. A series of leds indicating the status and activity of the microsystems will allow the tech team to spot the condition of the controller on the floor. Each slot machine will have its own microcontroller the microcontroller will connect to the machine buttons / electrical components via it digital and analog ports. For example: if you need to press a button then the button contacts will be replaces by a relay (electro-mechanical or solid state one) , The software will be loaded to the microcontroller locally via USB by the technician / manufacturer, software updates will be done In the same way. Configuration updates will be sent remotely and will reside on the microcontroller flash memory

2.2.5 CDN Services

The application will be using on market existing CDN services. The aim of the CDN services is to allow smooth game play, rapid game flow and to reduce time lag between the user actions and results seen on screen. The application will hold two major CDN service types one for static files and one for video streaming. The CDN provider will allow end point selection based on major client audience.

2.2.6 Slot Management BO (EX)

This is an off the shelf product integrated in to our application. Casino BO application accumulate real time game data fed to it by the different slot machines, that data is aggregated and analyzed, end results allows the end user ( pit manger, casino management, operator) to ascertain and monitor the validity of the slot machine winning ratio. The application is built to integrate data from different slot machines manufactures and has its own GUI and API. Hardware requirement are based on the selected BO application requirements. Main requirements: External reporting API Multi game manufactures support

10

template High Level Design

Real time push of games result per machine per round VIA API to our system. The data transferred needs to include bet and win amounts in credits. Pit manager reporting and monitoring module Compliance with the local authorities requirements

2.2.7 Chat server

This is an off the shelf product integrated in to our application. Chat server aim is to bring the social interaction of the end user with the application. Hardware requirement are based on the selected chat server application requirements. Main requirements: Public and private room support Admin functionality for the hostess conversation managements External API for integration with casino application: o reading user data o interfacing with the end user and in-house rich clients Log saving for auditing purposes Server must be robust and allow up to 2000 concurrent sessions Support of voice chat in private room Allow exclusion of users by pit boss. Multilingual support including eastern languages. (Japanese Cantonese)

2.2.8 Application servers

The application server will hold the Casino application form game management to reporting and integration application. Casino operations require an on premises solution due to the nature of the application, there for we will base the solution on a set of VM machines with a redundancy availability of 20%. The servers will be fitted with a monitoring capabilities hot backup and redundancy management systems.

2.2.9 OLTP DB Server

Fast performance DB server supporting online operation. Will provide data services to the following applications modules: Configuration and real time management: holds the list of live slots current state and availability, same for hostess. In addition will track game progress providing cashing and control support to the application User base: will handle the user base as an aggregation from all the different operators. User data will be provided by the operators as one of the first integration platform actions. Operator configuration and information. The gaming platform and integration services will be the sole user of the DB.
11

template High Level Design

Requirements: Relational DB features support RDP scenarios support for up to the second live back up hot recovery option On premises support for clustering mirroring or replication solution Encryption support for gambling regulation standards

2.2.10

Reporting BO Server

The following DB servers is considered a VLDB it main usage will be to hold game history. Accompanying the server an ETL application to migrate and accumulate data origin in the fast history DB. The server will host several Databases : Recent history for fast data insertions and reads Archive old game play for archiving purposes supporting large data volumes DWH eco system built for aggregation and reporting NonSQL DB second stage reporting development when raw data reaches 1T The game history saved will serve the following functions: End user will be able to view former games Reports for the operator Support team inquiry Fraud investigation Requirements: Relational DB features support due to the consistency required by the regulation standards RDP scenarios support for live back up hot recovery option Data compression and partitioning

2.2.11

Monitoring log

Will ingrate an out of the box monitoring system. The system will report errors application and hardware and create alerts and escalate

2.2.12

SAN

The SAN device will support the storage requirements for the different application servers DB and external applications. For requirements please check the hardware section below.

12

template High Level Design

2.3 System components (logical)

This section describes the central logical components of the system (as appearing in the diagram)

2.3.1 Operator
The logical unit of the Operator represents our clients.To whom we are providing the live floor casino service. Technology and unit platform are under the jurisdiction and responsibility of the operator. The unit holds the user information and bankroll and will manage chase deposits and all the money transactions involved with the end user funds including history saved risk management deposit fraud detection and preventions. The live floor casino application will consider the data provided by the operator as accurate and up to date and will not try to validate it on its own account.

13

template High Level Design

Main functions required Login and authentication end user Get user data to the integration service Funds wiredraw Funds deposited Optional functions Game round results receive and store Request report from the casino

2.3.2 Presentation Layer

The sole purpose of the presentation layer is to provide robust and rich GUI to the end users. The module must be built to support multiple platforms hence the same backend service should support multiple GUI options. To reduce time leg and insure good user experience the presentation layer should be placed as close as possible to the end users. It will implement CDN services for static file and Streaming CDN for the video feed. Since the presentation layer doesnt include private user information it will be designed in advance to be placed in off premises locations (will only be implanted in the second stage could be placed on the cloud ) The presentation layer will utilize Responsive design methodology, providing an optimized viewing experience with minimum changes to the viewed screen across multiple platforms.

2.3.2.1 Cashing\Front
This is the Proxy cashingpart of the application holding public data to be presented to all users. Such as machine mapping, machine betting limits, error messages, assets available slot machines, hostess, JP balance, video streaming lists. Data will be held in a format readable to all the different lobby clients ( See below ). This cashing application only, no specific logic is defined per user. Scaling the application is done by multiplying servers. At the second stage the application should be migrated to the cloud utilizing Global CDN services assuring the quick delivery to end users. Main functions required Read slot list hostesses list from gaming platform Format read information to designated format Cash data for delivery Hold slot queue

2.3.2.2 Lobby
Rich Client side GUI built in HTML 5 to support multiple platforms. There will be different presentation formats based on the end user platform ( see below ). The aim is to

14

template High Level Design

invite client to use the slot machines and hostesss services (see BRD for more information) Main functions required Select presentation format when loaded the lobby will build the presentation format base on the end user platform using dedicated configuration file per platform.Since the screen size and user interface differs from on platform to another an appropriate GUI supporting the appropriate screen size and control options. Read data from cashing front Read user data from integration server Present touring hostess video feed and chat connection Select private hostess Select slot open game client window Display live streaming media Multilingual and multicurrency support Walk around camera feed Display a synchronized player balance Support messages to client (ticker) Handel waiting queue alert for a specific slot user will mark that he wants to play on certain slot if it is occupied and will receive an alert to lobby or client when slot is available

2.3.2.3 Game client

The game client is the place the actual game is played and a direct communication with hostesses takes place. Client will be fitted to match the displaying platform including control changes (touch screen mouse ...) Same as the lobby game client will be developed using HTML 5 Main functions required Support video streaming In a private hostess machine support these extra features o Integrate chat server application o Connect to gaming platform request private hostess information and select one to join game play Connect to gaming platform request slot machine Connect and display video feed of selected slot Connect and display video feed of selected touring hostess Play slot: o Deposit money ( request withdraw from operator) o Place bet o Play round o Cash out (return money to the operator account) Return to lobby Notify when a specific requested machine is available

15

template High Level Design

Messages to the client Manage the stream settings mute /resolution /full screen mode.

2.3.3 Integration Server

The integration server is responsible for the communication with the operator service. It main goal is communicate with the operator API( there are many API one per operator but all have the same functions) retrieve data format the structure to the one used by the casino. All used data and financial actions are carried out by the integration server. One of the main characteristics of the integration server is persistency; this ensures the integrity of the financial transaction in the wide verity of frequent as well as unique borderline cases.

2.3.3.1 User management

The user management modules provide interface to the end user personal data related tasks. Main functions required Authenticate process between integration server and operator Automatic re authenticate on game flow. Receive user data store in locale casino user DB

2.3.3.2 Transaction management

The transaction management is responsible for online communication of financial activities on the player origin wallet on the operator side. It initiates the calls and manages the responses received from the operator side. The implementation will see a single set of API that will be modified per operator requirements. These set of API's will also report back to the operator the entire game log of the player as part of the credit call. Main functions required Get balance - Receive user current bankroll - for display prepossess Debit call withdraw money from the bankroll at the operator platform Credit call deposit the end user account at the operator platform

2.3.4 Gaming platform

Logical component of the gaming platform aim is to manage the live sot floor and provide the faade between the physical part of the casino to the slot floor application. This is the core of the live floor application that synchronizes between the different modules external, internals, physical and virtual.

2.3.4.1 Slot management

The slot MNG module is responsible for management of the floor available machine and smooth operation.The application is built from two major parts configuration and slot availability. Configuration main functionality

16

template High Level Design

Define a slot. o Insert slot information: type , name description language support ID o Insert bet related info : available betting options , payout , JP Connection o Insert game play configuration : existing buttons and layout can be used with private hostess o Duplicate machine for fast creation of a new machine o Edit configuration information o Notice you cannot delete a slot machine Slot availability Configure slot availability list is limited to vip clients only English speaking only .. Set slot status o Operational status is the slot available to game play o Occupy slot user selected the slot Return slot list and slot information

2.3.4.2 Hostess MNG

The Hostess MNG modules manage the floor available hostess their current position, availability, connection information and communication with the support and pit boss functions. Configuration main functionality Define a hostess in the system o Insert hostess information: name, description language support ID o Duplicate hostess record for fast creation of a new record o Edit configuration information o Notice you can not delete a hostess from the application DB Hostess availability Configure hostess availability options o Define if hostess is limited to a client list ( VIP) ? o Define hostess language limitations o Define hostess slot hosting options ( can any host work with any slot) Set hostess status o Is the hostess available to private game play o Only working as touring Return hostess list and hostess information

2.3.5 Gaming DB
The gaming DB is built form several data schemas (table groups with functionality related to each other). It is an OLTP DB by design built for small number record insert and restore at one operation

17

template High Level Design

2.3.5.1 Dictionary Schema

Basically this schema hold a selection of table holding enum values used by the application, its main function is to support DB integrity using FK.

2.3.5.1.1 Main Entities

o o o o o o o Country list Language list Slot type User interface option ( buttons leavers ) Hostess type Slot availability status .

2.3.5.2 Configuration Schema

Holding configuration information on the different components of the live floor casino: slot machines, hostesses, JP , play line definitions, related dictionary information. The data is basically static and only seldomchanges; it is the perfect candidate for cashing in the presentation layer.

2.3.5.2.1 Main entities

o o o o o o o o Slot list Slot availability options Hostess list Hostess availability options Video camera list Connection between video and hostess Connection between video and slots Integration server configuration ( authentication instruction protocols ) o Operator list o

communication

2.3.5.3 User Base

For tracking security and reporting purposes we will keep in the DB a record per operator per end user. The information will be received as part of the integration service authentication process

2.3.5.3.1 Main entities

18

template High Level Design

o User record will hold the basic information of the user usually the mutual ground to all operators. Name , operator id last login time casino floor unique id o User extra information this is a none essential user level data like age .

2.3.5.4 Gaming DB
This is the most active schema, it will hold game play data per logged in user. The DB will serve as a persistent chasing layer for the different game servers, that way the application can remain stateless and the next action can be taken care off by any of the servers.

2.3.5.4.1 Main entities

o Game :User to slot connection current gaming state, how much money is in the game balance . o User to hostess connection o Slot waiting list o Game to integration server state action, withdraw and deposit actions taking place.

2.3.5.5 Gaming Control

The game control is the central hub for all the live floor different components, with the exceptions of the integration layer it holds the main flow logic of the application, error handling, consistency checks and game play control. Main functionality: o Manage game play o Return available slots o Return available hostess o Check for conflicts and roll back game plays o Create and store history record

2.3.6 Reporting
The reporting a platform is a complex system design to absorb massive amount of event records from round play to private to hostess requests, then aggregate the raw data creating as the end result data ready for predesigned reports.

2.3.6.1 Reporting APP

The reporting application has two major functions serving as the gate way to the reports data. On function will be managing connections and restrictions by holding login information, query restriction and building the report query according to the restriction the second part is a presentation layer presenting reporting options and results to the end users.

19

template High Level Design

2.3.6.2 Reporting DBs

The reporting layer is built from several DBs, data will be divided between the DBs based on the data functionality.

2.3.6.2.1 Main Entities

o Configuration and management db o Report type table o Login to permission o o Raw data logging holds a record per event o Game play o Hostess request o Slot queue o o Aggregation and reporting holds aggregated reports data for quick recovery results o Aggregate earnings per operator per date o Slot Machine usage o

2.3.6.3 Reporting DWH

The DWH is responsible for ETL process in the reporting layer. Transforming the data for a heap of raw data to valuable aggregated reports ready data.

2.3.7 Slot Management BO (EX)

An off the shelf product logical unit existing in every live casino, will use the same logical units as any live casino.

2.3.7.1 Data Assimilation

An api used by the slot machines to report gaming events. The layer will load different reports structure in to one data structure manipulate it to a format that will allow result analytics

2.3.7.2 Pit manager

The end user looking at the reports generated by the application will be using this logical unit to manage the slots examine game rounds and decide on the legitimacy of the slot machine.

2.3.7.3 Reports and Analytics

Built as part of the system providing the reports data that support slot machine validity. Will also be used by live floor application to report back the results of a game round.

20

template High Level Design

2.3.8 Video
The video component is responsible to stream the video feed form with in the casino to the end user and log the activity of the slot machines Main functionality: Capture video and voice feed using IP cameras see physical for more info Management and streaming system Serve as a directory and lookup server for clients wishing to access certain camera, the camera will be searched according to position (corridor junction for the 360 degrees camera ) or by slot machine ID , this server will also monitor and keep the status of each camera and will provide alerts and notifications to the operators regarding the camera status . Store game play video for later viewing. Stream data to end user, with integration to video streaming CDNs if required The management server will log the system events and camera usage Alerts will be sent from the management server to the operators using mail and event to the general monitoring application.

2.3.9 Slot machine take over

The takeover machine is built from two logical blocks. The server side and the node side, the node is a microcontroller with peripherals that Support communication protocols, have some logging capabilities mainly for debugging purposes and usage tracking. The Server side resides on a server and contain two types of interfaces, first is the interface with the controller, done via simple tcp/ipsocket, the other interface expose web-services based API to the outer systems.

2.3.9.1 Microcontroller
Main functionality: Receive simple commands via string ( such as "1" = press button 1 , "d" = send back diagnostic data ) Hold X ( minimum 100 ) recent commands received by the microcontroller ( memory card is optional in that case , we might use the microcontroller internal flash ) The microcontroller can in some cases hold a verifying hardware that will check if a button was pressed properly.

The technology in use: There are several options. Currently it seems we shall use a microcontroller from the Arduino family. It will be accompanied with a Ethernet shield .The microcontrollers it will be programmed via the Arduino C language version.
21

template High Level Design

2.3.10

Server Side

Main functionality: Provide access to the node functionalities via SDK the node access will be protected by software mechanism that will prevent more than one player to access it (in java it will be implemented as synchronized object with session lock) this mechanism is provided as a safety measure, the access to the node should be restricted to one player by the calling application. Provide status of all nodes Alert on node failure Recovery mechanism: source of failure can be in one of three places:server, communication medium ( Ethernet) , node. In case of node disconnection it will be the server responsibility to contact the node by using a repetitive polling of node connection. In thecase the server is shutting down and restarting it will receive by node TCP/IP addresses and will be responsible to call them one after the other till connection is established between them all. At the second phase a initial handshake / recognition process will be programed in to the nodes, by the node calling the server in order to list itself up.

2.3.11

Monitoring logging

The monitoring layer will serve as the focal of the whole application platform. The different parts of the application will report back logical error to the monitoring app on errors and monitoring agent will be implemented in the application for external monitoring. The errors will trigger event in the application resulting escalation and reports back to the first level support on premises.

22

template High Level Design

3 System main functionalities

This is the main section of the document defining the main functionalities our system facilitates:

3.1 Game play

3.1.1 General
The diagram represents the main flows in the process of a single game play round. Occupy machine initiation of a game start.User selects a machine and sits down money is transferred to his current bankroll from the operator. Single Round Play - play one round from bet to results, multiple rounds are a repetition of the flow of a single round. Reload funds the process of requesting funds or withdraw action form the operator. Cash out return funds action takes place when a user closed a game window or bet round is completed funds are automatically returned to the operator bank roll. The same process will take place if the action was initiated by the user or as a result of an error.

o o o o

23

template High Level Design

3.1.2 Flow diagram

24

template High Level Design

3.1.3 Error handling/messages

o Insufficient funds while attempting reload funds operator refuses on the grounds of insufficient funds. Display pop up at client side explaining the issue. o Cash out fails cant return funds to operator. Display error msg to client create alert with details to floor support team. o Reload funds fail retry process again if fails report to the support team display error msg to client asking to try again later . o Cant read round results freeze game client alert pit manager on issue o Video feed cut off alert pit boss remove slot availability suggest different slot to client

3.2 Join Hostess 3.3 Join Hostess

3.3.1 General
How a user selects a hosts and connection process between the end user client to the hostess client and the communication components

25

template High Level Design

3.3.2 Flow diagram

3.3.3 Error handling/messages

o Disconnection display reconnect button on end user client, for chat and video feeds
26

template High Level Design

o Insufficient funds in the case of private hosting if there is no money in the end user balance: display warning on client screen with a countdown saying screen will be darken in ..

3.4 History
To allow transparency and help with operator support we will allow access to our reporting platform from an external interface. The operator will have to login to our BO system the reporting app will keep session info on the login and will check for user right before performing any report and displaying results.

3.4.1 Flow diagram

3.4.1 Error handling/messages

o Disconnection return user to login screen start process from start o Security error close session ( cancel login) ALERT support team o Video not found display error msg, alert support team ( include video operator data )

27

template High Level Design

3.5 Slot Queue

Slot queue are used to keep the client in the system and allow him to spend money on other slots while waiting to the desired slot

3.5.1 Flow diagram

3.5.2 Error handling/messages

28

template High Level Design

4 Hardware components in the system

4.1 General
Listing the HW components that will be in use in the system Microcontrollers DB Cameras SAN - NETAPP Application server Video management system

4.1.1 Application server

Our application server solution is built from hardware and software combination. The hardware provider should support no single point of failure. It seems that our best solution would be to start with 2 servers with the following configuration: Start 2 quad CPU support scallop to 8 Start 16GB support to 128G 4 1\10G network cards 2 Fiber SAN Hubs 2 power supply Remote management option We are looking for a virtualization solution either ZEN or VM can be selected. We will distribute work load between servers but allow enough redundant resource in the case of hardware error in one server. The minimum configuration above should support 8 application servers and 3 DB servers. At later stages we can scale up the CPU ad memory to allow up 50 application servers and more robust DB servers. At feature we can scale out adding additional servers. The second part of the solution is a virtualization system preferably VMware ( but XEN will also do) . The selected solution should include the following modules: That support linux and window Hot backup and recovery Image duplication with name and ip control ( new image must have a new server name and IP address to prevent collisions) . Hard resource allocation option
29

template High Level Design

4.1.2 SAN
Our SAN solution will support the application server storage requirements video storage for history and the DB requirements. A NETApp Mid-level solution will do, with following feature: Support to 30TB Storage Dual switch Support for RDP and snapshot External storage chaining

4.1.3 Machine control node

4.1.3.1 General
Will be built form a Case ( 10X10X10 cm ) with external power supply , and wires going out to the peripherals of the slot machine , it will have the on/off button , and communication ports for standard Ethernet cat-5 cat-6 cables

4.1.3.2 Set up and Configuration

Physical setup: each slot machine will have its own microcontroller the microcontroller will connect to the machine buttons / electrical components via it digital and analog ports. For example: if you need to press a button then the button contacts will be replaces by a relay (electro-mechanical or solid state one) , The software will be loaded to the microcontroller locally via USB by the technician / manufacturer, software updates will be done In the same way. Configuration updates will be sent remotely and will reside on the microcontroller flash memory

4.1.4 DB
The DB hardware is based on the application server and SAN components mentioned above currently there are no specific hardware requirements for the DB. We will start with the following a resource a locations OLTP SERVER : 1 CPU Dual Core 2 GB Memory 50 GB Hard Drive for data 100 GB Hard drive backup 150 GB for snapshot Reporting DB 2 CPU Dual Core 4 GB Ram

30

template High Level Design

100 GB Hard Drive for Data 150 GB Hard Drive Backup 200 GB snapshot

4.1.4.1 General
TBD

4.1.4.2 Set up and Configuration

TBD

4.1.5 Cameras

4.1.5.1 General
TBD

4.1.5.2 Set up and Configuration

TBD

31

template High Level Design

5 Performance (load model)

The system will support a floor of up to 500 machines, adjustments and tweaks will be made as part of the development and testing phases. The major focus in the performance aspect will be given to the delays for a single user initiating betting activities up against the machine (pushing the buttons). Another aspect will be the delays and performance of the steam will focusing on HD and HTML5 stream capabilities.

32

template High Level Design

6 Miscellanea / Appendices
6.1 Interoperability with other systems
6.1.1 Chat server
Redirect user to private and public chat rooms based on the current client state for example in the lobby the user will join public chat rooms used by the touring hostess

6.1.1 External BO system

See logic design

6.1.2 Video streaming and control

see logic design

6.1.3 CDN services

See physical design

6.1.4 Operator
See logical design

6.1.5 Monitoring
We will use an out of the box monitoring application using standard syslog and snmp traps will receive error report from the deferent modules display report on the main noc screen.

6.2 Expandability
This is a live floor casino application due to security and regulation it can not be extends or modified by third party with the exception of the APIs exposed by the integration layer.

6.3 Monitoring
Will use global monitoring system gathering date from the different application components. Logical application errors will be reported to the main monitoring application Monitoring agents installed on the servers Ip cameras and augmented cameras will be monitored by the management server that will report back Streaming solution will be monitored by its own monitoring utilities and if possible by interfacing to the streaming solution SDK through the management server
33

template High Level Design

The management server will be monitored by the operators using a web interface Microcontroller will be monitored by the takeover server and a set of leds indicting the microcontroller status

6.4 Security
We assume that the internal network is isolated from the web through the streaming servers and those servers are protected by proper firewall and other security mechanisms. Security issues can rise from tempering with the ip cameras remotely and of other system component, the issue can rise from denial of service attack to hijacking services and interfering with the camera proper operation by addressing its SDK . Injecting massive amounts of requests can cause the microcontroller node or the takeover server to lock or malfunction, thus the local Ethernet infrastructure should be isolated from the web accesses should be allowed only by internal network.

6.5 Open Issues

1) Wire or wireless communication 2) Server farm location 3) One node per one slot machine or have several machines per node ( price over convenience and redundancy) 4) Local log on the node (microcontroller) or provide limited log using the management server. The log mainly serve the security and debugging of the system 5) How long do we need to save history video data

34