G2S building block - Gaming Standards Association

fortnecessityusefulΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

183 εμφανίσεις

G2S Building blocks

May 2010

Green Valley Ranch
-

Las Vegas, NV

Ales Gornjec, Hermes SoftLab

How to speed up the implementation of
GSA standards into new products

Slide
2

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
3

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
4

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
5

Complexity
-

GSA Protocol sizes and growth

started

today (May 2010)

protocol

classes

pages

classes

pages

exten
-
sions

BOB
(2004)

16

300+

replaced by G2S

G2S
(2006)

22

1240

23

1825

7

S2S
(2004)

15

375

25

1130

2

SAS*

14

190

*SAS included only for comparison of spec and functionalities covered

Slide
6

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


V
endors 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
7

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
8

Timeline projection

Slide
9

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
10

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
11

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
12

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
13

Integration points and APIs


High level
API is easier to integrate


C
overs
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

Slide
14

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
15

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
16

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
17

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
18

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
19

Questions?