Transcript G2S building block - Gaming Standards Association

How to speed up the implementation of
GSA standards into new products
G2S Building blocks
May 2010
Green Valley Ranch - Las Vegas, NV
Ales Gornjec, Hermes SoftLab
Agenda
 Why GSA and G2S
 Approach to providing G2S solutions to
gaming machine vendors
 Why developing our own set of tools?
 Generic implementation versus specific
 Integration challenges and solutions
 G2S host and S2S protocol building blocks
Slide 2
Hermes SoftLab
At a glance
HERMES SoftLab is an international provider of
software engineering services & IT solutions





Established: 1990
Member of ComTrade Group since 2008
Headquarters: Ljubljana, Slovenia, EU
Employees: 850+
Main markets:
 gaming & storage industries
 telecommunication service providers
 financial institutions and the public sector
 Quality certificates: ISO-9001/TickIT by BSI
Slide 3
The need for GSA and G2S?
 For heavily regulated industries (like
gambling) standards are very important
 Single vendor environments are easier to
build but – players require variety
 Standards break vendor lock-in situations
 First important steps already made
 Now certification program and GSA university
are also available
Slide 4
Complexity GSA Protocol sizes and growth
started
protocol
BOB
(2004)
G2S
(2006)
S2S
(2004)
SAS*
today (May 2010)
classes
pages
classes
pages
16
300+
replaced by G2S
22
1240
23
1825
7
15
375
25
1130
2
14
190
*SAS included only for comparison of spec and functionalities covered
extensions
Slide 5
Hermes decision and goals?
 Previous experience with industry standards
 Knowledge transfer from other segments (XML, SOAP, security)
 The need
 Due to its complexity G2S requires significant investments (time,
resources, knowledge)
 Standards can’t be deployed successfully without wider vendor support
 Vendors are asking themselves:
 to develop or
 to buy and integrate?
 Implementation goals:




Compatibility with vendor platforms (OS and language)
Low resource consumption (ram and processing power)
Easy integration
Clear separation between protocol stack, integration and platform to
allow easy maintenance
Slide 6
Build or buy decision
Buy (+)







Shorter time line
Portable design
Clear and stable API
Proper support for extensions
Phased integration – low risk
from the start
Maintenance covered
Internal resources not locked
into long implementation
project
Build




Full control
No external dependencies
Optimal implementation and
integration into the platform
Possibility to reuse platform
features (persistence, logging, …)
Slide 7
Timeline projection
1 1 /1 0 - 1 2 /1 0
7 /1 0 - 8 /1 0
C o re
c la s s e s
in te g ra tio n
6 /1 0 - 6 /1 0
F e a s ib ility w o rk s h o p
C e rtific a tio n
and
v e rific a tio n
8 /1 0 - 1 1 /1 0
F u ll in te g ra tio n
7 /1 0
1 0 /1 0
1 /1 1
1 /1 1 - 7 /1 1
in te g ra tio n a n d p la tfo rm a d ju s te m e n ts
5 /1 0 - 7 /1 0
7 /1 0 - 9 /1 0
9 /1 0 - 1 0 /1 0
In itia l
in v e s tig a tio n
K n o w -h o w g a th e rin g
In fra s tru c tu re
im p le m e n ta tio n
7 /1 0
1 0 /1 0 - 6 /1 1
G 2 S C la s s im p le m e n ta tio n
1 0 /1 0
1 /1 1
1 /1 1 - 7 /1 1
in te g ra tio n a n d p la tfo rm a d ju s te m e n ts
7 /1 1 - 1 0 /1 1
1 0 /1 0 - 6 /1 1
C e rtific a tio n
a n d v e rific a tio n
G 2 S C la s s im p le m e n ta tio n
4 /1 1
7 /1 1
1 0 /1 1
Slide 8
Project – investigation & planning
 High level management decision: we need G2S!
 Project team is formed to




study the protocol basics,
investigate feasibility and
prepare high level estimates
takes 2 months, estimates 10 EM for basic implementation
 Implementation team is formed to prepare




high level architecture,
designs and
project plan
takes 3 months, plan to finish in 8 months, discovered that testing will
be difficult and testing tools need to be developed or acquired
...
Slide 9
Project risks
 When building own solution for G2S
 Resources
 Engineers
 Know how
 Product:
 Performance impact
 Interoperability
 Compliance
 When buying and integrating
 Platform compatibility
 External dependencies
 Difficult to evaluate quality in advance
Slide 10
Platform requirements
 Persistent Memory usage
 G2S with three main classes: ~6 kB raw data (30kB
with SQLite)
 G2S with all 23 classes: ~84 KB raw data (150kB with
SQLite)
 Minimal system requirements
 Memory (RAM): 20 - 50 MB
 CPU consumption
 Game-cycle simulation: about 20ms/cycle
 That is 50 games per second can be simulated on a
dual-core PC
Slide 11
Phased integration process
 Main goal is to identify and mitigate risks as early as possible
 Designed in a way to answer critical questions early:
 Is platform able to fulfill G2S requirements ?
 Integration feasibility (interfacing, process and threading model,
resource management...) ?
 Hardware: are CPU and memory resources sufficient ?
 NVRAM usage
 Prof of concept phase gives basic working integration
 Additional functionalities integration is dictated by customer
and it’s priorities
 Final phase helps with certifications and product deployment
Slide 12
Integration points and APIs
 High level API is easier to integrate
 Covers 90% of class functionality (ordinary use)
 Can be combined with raw G2S API for special cases
 Raw API is a direct mapping of G2S commands:
 Classes
 Commands
 Similar structures
EGM Platform Adapter
Persistency
Adapter
G2S Classes
Application Services
EGM Platform
Technical Services
Foundation (Platform Abstraction)
Slide 13
Protocol versions and maintenance
 Currently 2 major G2S version branches (1.0.3 and 2.0.3)
 Only deployment of version 1.0.3 is publicly known
 Several S2S versions released
 Several version deployed
 Several dialects
 Interoperability problems quite common
 Maintenance cost can be considerable
 Upgrades to new versions
 Interoperability fixes
 Backward compatibility issues
 Using a generic implementation is a good path to
 Reduce costs,
 Reduce interoperability issues and
 Shorten time to market
 HSL host implementation provides multi-version support
Slide 14
Supporting G2S tools
 Needed for stack development and testing
 Internal tools allow our own pace for supporting new versions
 Possibility to develop different incarnations
 Complex GUI for manual testing
 Console application for load/performance testing
 Scriptable client for test automation
Slide 15
Testing
 Unit testing
 over 200 unit tests, cover all G2S commands
 System testing
 test cases for each class ( 30-100 test cases per class)
 Automation
 host simulator workflows
 Performance
 latency and CPU usage measurement
 Stress testing
 using command line EGM simulator
 EGM simulator instance with 200 game devices ~16MB of RAM
 for 1000 instances, 16GB RAM.
Slide 16
Interoperability
 Problems seen:




optional commands, elements and attributes
protocol versioning
protocol backward compatibility is not 100%
problems with extensions
 How to improve:




defensive approach to design and implementation
design with multi-version in mind
version and extension agnostic APIs design
protocols need to improve in this area too
Slide 17
What is still ahead of us
 Wider product support (both host and EGM side)
 Push seen from distributed gaming side (lotteries)
 Individual deployments with some operators
 Push in some jurisdictions
 Initial interoperability issues resolved
 Still a lot of work needed
 Improvements in products based on new features available
 Bigger push /need from operators will come after that
Slide 18
Questions?
Slide 19