WO1998030966A1

WO1998030966A1 - Casino intranet gaming system

Info

Publication number: WO1998030966A1
Application number: PCT/AU1997/000890
Authority: WO
Inventors: Ian Noel Farnsworth; Alasdair Dougal Mcburnie
Original assignee: Crown Limited
Priority date: 1997-01-06
Filing date: 1997-12-30
Publication date: 1998-07-16
Also published as: AUPO446997A0

Abstract

An Intranet gaming system using TCP/IP as the communication protocol and used in a casino type gaming environment. The Intranet gaming system having a central control unit acting as a host or server for a number of table top devices connected via an Ethernet.

Description

CASINO INTRANET GAMING SYSTEM

FIELD OF INVENTION

The present invention relates to a table gaming management system, and particularly those used in casinos. The present invention also relates to table top devices used in such gaming systems and communication methods used in such gaming systems. BACKGROUND

Table automated gaming systems developed to date suffer from a number of disadvantages. These type of systems often do not provide all the features that are needed today by gaming system operators. Some of the features needed include, user friendly interfaces, back betting, dealer analysis, relatively low cost per unit, and central control and information storage in case of corruption of records.

The disadvantages/problems of the current systems are: Poor scaleability of server architecture,

Use of IPX communication,

Rating of no more than 2 players / table,

Local based transaction management which is susceptible to corruption,

Unable to service multiple tables simultaneously, No ability to perform game result counting,

Unable to perform dynamic remote configuration of table devices from server,

Poor table device reliability,

No server redundancy, No continual server synchronization,

Does not have an electronic drop input device,

User interface clumsy,

Inferior and slow serial communication. SUMMARY OF INVENTION An object of the present invention is to alleviate at least one of the disadvantages of the prior art. The present invention uses a TCPIP protocol in conjunction with a server architecture as a basis of communication and system design for a gaming system. It has been found that the adoption of this TCPIP protocol and server architecture to the environment of gaming systems, a number of the disadvantages attributable to the prior art can be overcome. More importantly, it has been found that the present invention is able to provide a number of features previously not possible in prior art systems.

Some of the advantages over prior art systems are considered to be: server based transaction management, - TCPIP generates relatively less network traffic,

TCPIP can provide a relatively stable working environment, TCPIP is not dependent on the LAN server running, UNIX type platforms can be run, providing scaleability and relatively greater functionality than a PC type server environment, - relatively easily interfaced to existing applications, no special / proprietary cabling is required to be run. This in turn offers better scaleability and flexibility of system operation, software upgrades are relatively easy, server redundancy. Embodiments of the present invention will now be described with reference to the accompanying drawings, in which:

Figure 1 illustrates in schematic form a preferred implementation of the present invention,

Figure 2 illustrates an alternative embodiment of the present invention, in which IPX as the communication protocol, and

Figure 3 illustrates a further alternative of the present invention based on a serial connection configuration of the gaming system.

The invention allows any number of Table Top Devices (TTDs) to be connected to any section of the Ethernet and locally grouped to a primary server and a secondary server in case of primary server failure. NOTE: A primary server does not need to act as a secondary server for its secondary server. Figure 4 illustrates various protocols at the different layers in the TCPIP protocol suite,

Figure 5 illustrates the encapsulation of TCP data in an IP diagram,

Figure 6 illustrates more detail of the TCPIP protocol suite, and Figures 7A and 7B illustrates an example of a Table Top Device (TTD) suitable for implementation with the present invention.

The underlying principal that the system is built around is the use of TCPIP as the communication protocol. It is the use of this proven protocol that allows fast, reliable communication. Without using this protocol it would be difficult to perform the above functions reliably, if at all. Overview

Server Based Architecture

A host based server architecture is one that;

All application data is stored on the host, as well as locally on the client. Every transaction that effects the local data must establish a communication channel with the host to transmit the transaction details thus ensuring the client and the server are always in synchronization.

Should a transaction fail while in transit the local transaction must be reversed before re-transmission. TCPIP Standards

There are four groups that control the TCP IP protocol suite and approve new standards, these are:

Internet Society,

Internet Architecture Board, Internet Engineering Task Force,

Internet Research Task Force.

These standards are published as a Request for Comment, RFC. There are a lot of RFC's that are published that are not official standards but are published for information purposes. The PCTCP software that is used conforms to these standards as well as networking standards outlined by the Institute of Electrical and Electronics Engineers standards, known as the IEEE 802 standards. TCP/IP protocol suite is the combination of different protocols at various layers.

TCP/IP is normally considered to be a 4 layer system, (see Figure 4): 1. Application FTP, E-mail 2. Transport TCP, UDP

3. Network IP

4. Link Device driver and interface card. Each layer has a different responsibility:

The link layer, alternatively called the data-link layer, normally includes the device driver in the operating system and the corresponding network interface card in the computer. Together they handle all the hardware details of physically interfacing with the cable.

The network layer handles the movement of packets around the network. Routing of packets, for example takes place here. IP (Internet Protocol) provides the network layer in the TCP/IP protocol suite.

The transport layer provides a flow of data between two hosts, for the application layer above. In the TCP/IP protocol suite there are two vastly different transport protocols: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), see Figure 6. TCP provides a reliable flow of data between two hosts. It is concerned with things such as dividing the data passed to it from the application into appropriate sized chunks for the network layer below, acknowledging received packets, setting timeouts to make certain the other end acknowledges packets that are sent, and so on. Because this reliable flow of data is provided by the transport layer, the application layer can ignore all these details.

UDP, on the other hand, provides a much simpler service to the application layer. It just sends packets of data called datagrams from one host to the other, but there is no guarantee that the datagrams reach the other end. Any reliability must be added by the application layer. The application layer handles the details of the particular application.

There are many common TCPIP applications that almost every implementation provides: 1. FTP File transfer

2. Telnet for remote Login

If we have two hosts on a local are network such as Ethernet, both running FTP Figure 4 shows the protocols involved. Why use TCPIP protocol suite?

In the TCPIP protocol suite the network layer, IP, provides an unreliable service. That is, it does its best job of moving a packet from its source to its final destination, but there are not guarantees. TCP, on the other hand, provides a reliable transport layer using the unreliable service of IP. To provide this service, TCP performs timeouts and retransmission, sends and receives end-to- end acknowledgments and so on. The transport layer and the network layer have distinct responsibilities. The combination TCPIP therefore provides many advantages in its implementation to gaming systems.

TCP provides a connection-oriented, reliable, stream service, in that using TCP must establish a TCP connection with each other before they can exchange data. TCP was selected because of how it provides reliable communication.

• The application data is broken into what TCP considers the best sized chunks to send. The unit of information is passed by TCP to IP is called a segment.

• When TCP sends a segment it maintains a time, waiting for the other end to acknowledge reception of the segment. If an acknowledgment is not received in time, the segment is retransmitted.

• When TCP receives data from the other end of the connection, it sends an acknowledgment. This acknowledgment is not send immediately but normally delayed a fraction of a second.

• TCP maintains a checksum on its header and data. This is an end-to-end checksum whose purpose is to detect any modification of the data in transit. If a segment arrives with an invalid checksum, TCP discards it and does not acknowledge receiving it. (It expects the sender to time out and retransmit). • Since TCP segments are transmitted as IP datagrams and since IP datagrams can arrive out of order, TCP segments can arrive out of order. The data is resequenced in correct order if necessary and passed to the application. • Since IP datagrams can get duplicated, a receiving TCP must discard duplicate data.

• TCP also provides flow control. Each end of a TCP connection has finite amount of buffer space. A receiving TCP only allows the other end to send as much data as the receiver has buffers for. Expanded Detailed Description

A TTD is plugged into any port on the Ethernet. It then dynamically populates any / all configuration tables using BOOTP and FTP to download any configuration information. The TTD application starts and all outstanding transactions are retrieved via communication with the server. Fast, reliable communication with the server is achieved by dynamically allocating TCPIP sockets when communication requests need to be processed. How TCPIP and Server architecture interacts

Referring to Figure 1 , a TCPIP Network Architecture is illustrated in which: A) Database server process B) TTD Server → Database process

C) TTD Server broadcast message

D) TTD Process

E) Broadcast message

F) Dynamically allocated TCPIP connection between D and X-| ...X_n The UNIX server has at a minimum 3 processes running that are used for communication with the TTD's. These processes are:

A) Database interface program.

B) TTD Server → Database interface program.

C) Server broadcast message program. When a request for communication is received there can be X-| ...X_n processes started by process B where n is the number of open requests being processed by processes A and B. (These are referred to as child processes). Once the transaction has been serviced by processes A and B process X_n closes.

When the TTD requires to communicate with the server the process is as follows: 1 ) Process C continually broadcasts server status information on a known UDP port number. The status information is as follows:

• Server status (active or inactive)

• Server groups ( a list of active pits that can be serviced by the server). • Current version of software.

• New version of software.

• Pits that can download the new software version.

• Current time and date for synchronization purposes.

2) The TTD contacts process B on the known UDP port number to request a TCPIP port number to communicate on.

3) Process B allocates an ephemeral port number (Dynamically generated TCPIP Socket) for the TTD to communicate on and sporns a child process for the TTD to communicate with.

4) The child process reads the information from the TCPIP socket, which is sent using in IP data segments, and sends this information to process B which in turn sends the information to process A.

5) The database server reads the request, stores the request in the current database and in the redundant database, builds a response and sends it to the child process. 6) The child process sends the response through the TCPIP socket to the TTD which acknowledges the arrival. 7) The TTD closes the socket and with the knowledge of a completed transaction the child process closes.

When a new version of software is to be released the following process is completed:

1. The server is placed in an inactive state to ensure that no transactions are processed while the software is being updated. 2. The server broadcasts the current version of software and the new version of software that is to be downloaded and which areas are to be updated.

3. The TTD parses the TCPIP broadcast message and ascertains whether it should download the executable. 4. The TTD downloads the new executable using FTP (which is using

TCPIP to send the file), verifies the new version and restarts the application.

5. When all units have been upgraded the current version of software is upgraded and the server is activated to allow transactions to be processed.

6. Units that were powered off when the message was broadcast will, when powered up, parse the current broadcast message and identify that the version of software that they are running is not current. The unit will go through steps 4 and 5.

Server Redundancy Functional Description

The server broadcast message contains information about the valid groups that the server can service and the status of the server, inactive (not accepting requests) and active (accepting requests). When the system is configured with a backup server an additional process is running on each UNIX server that is continually monitoring the status of the primary server. When this process notices that the primary server is down the background process; 1. Issues a request to make the primary server inactive. This is done in case the primary server comes back up while the server switching process is running.

2. Issues a request to make the backup server inactive.

3. Copies all open and uncommitted transactions in the backup database where the server id matches the primary server id to have the backup database id. It then changes the status of the primary transaction in the backup database to be committed.

4. Marks the backup server to indicate that it backing up the primary server. 5. Marks the primary server to indicate that it is being backed up.

6. Generates new configuration files for the backup server to include the TTDs that usually run off the primary server in addition to the TTDs that normally run off the backup server. 7. Issues a request to make the backup server active. When the background process notices that the primary server is running again it; 1. Issues a request to make the backup server inactive.

2. Commits all outstanding transactions in the primary database where the server id is the primary server id.

3. Copies all open and uncommitted transactions from the backup database to the primary database. 4. Commits these transactions in the backup database.

5. Generates new configuration files for the backup server.

6. Marks the primary server as not being backed up.

7. Marks the backup server as not backing up the primary server.

8. Issues a request to make the primary server active. 9. Issues a request to make the backup server active.

IPX IMPLEMENTATION

An alternative to the TCPIP described above is IPX. Referring to Figure 2, an IPX configuration is illustrated in which: A) Database server process B) TTD Server → Database process

C) TTD Server broadcast message

D) TTD Process

E) Broadcast message

F) Communication between D and C The IPX server has at a minimum 3 processes running that are used for communication with the TTD's. These processes are:

A) Database interface program.

B) Server TTD → Database interface program.

C) Server broadcast program. Each TTD would have a logical address assigned to it being the table ID number. This ID would prefix all TTD messages that are sent to the server. The TTD would be plugged into the Ethernet to allow communication with the host. The server process would broadcast the following information every x sees to all TTD's on the network:

The state of the server.

Address of the server.

Active groups.

Current version of software.

New version of software.

Update group list for new version of software.

When the TTD requires to communicate with the server the process is as follows:

1. A TTD would broadcast a message with the server's address until it received a response or a time-out period was reached.

2. If the time-out period was reached the TTD would report an error message and the transaction would be re-tried. 3. The server would receive the message and broadcast a response until it received an acknowledgment that the transaction had been received or a time-out period was reached. 4. If the time-out period was reached an error would be logged in the database and the server would disregard the message. 5. The TTD would have to filter out responses that were not meant for it, waiting to hear the response to the message it sent. 6. The TTD would then process the message and broadcast a response back to the server that it received the message for a pre-defined period of time. If the server did not hear this response then the TTD and server would be out of synchronization which could result in data corruption.

For redundancy the database on the server would be synchronized with a backup database. In the case of the primary database failing the backup database would start up and process all new requests.

The TCPIP approach is preferred to IPX because in IPX: • A TTD cannot have a dedicated connection with the server thus everything must be broadcast. This may generate a large amount of network traffic and the application may spend a lot of time filtering out messages that were not meant for it. The server may spend a lot of time processing messages that it had already received and processing acknowledgment messages. • To update a new version of software using IPX, the server would have to: 1. Process a request from the TTD to receive a new version of code.

2. The server would then have to broadcast an image of the code for the TTD to process and load. This would generate a relatively large amount of network traffic and the software may be complex to process and load the code image that is being broadcast. • With all messages being broadcast the manner in which the TTD and server acknowledge messages is sometimes considered clumsy and susceptible to the TTD and server being out of synchronization. This may result in data corruption. SERIAL CONFIGURATION Still a further alternative is illustrated with reference to Figure 3, in which:

A) Database server process

B) TTD Server → Database process

C) TTD Process

The UNIX server has at a minimum 2 processes running that are used for communication with the TTD's. These processes are:

A) Database interface program.

B) Server TTD -> Database interface program.

Each TTD would have a logical address assigned to it by which port it is plugged into on the serial interface board. There would be two communication ports on the TTD that would be wired back to the primary and secondary server. The server process would send a data message every x sees to 1...n TTD's on the serial interface board informing them of the status of the server. If a TTD did not receive a status message from process B on the primary server it would try to communicate to the backup server on its secondary server. When the TTD requires to communicate with the server the process is as follows: 1 ) The TTD would send the information to process B. 2) The database server reads the request, stores the request in the current database and in the redundant database, builds a response and sends it to process B.

3) Process B would send the response back to the TTD. The major problems with this approach are:

1 ) Extra hardware is required to achieve a redundant model. Even then the algorithms to achieve the redundancy would be extremely difficult because the redundancy is being monitored through two separate hardware devices not one as in the TCPIP implementation. It would be difficult to ascertain whether a communication loss was due to the server being down or a faulty port. Whereas with the TCPIP implementation a loss of communication is common between both servers.

2) Dedicated cabling would have to be run.

3) It would not be possible to achieve communication through serial as fast communication with TCPIP. Communication across Ethernet is usually

10 million bits / sec and across serial it is up to 100,000 bits / sec. The order of magnitude in difference makes it infeasible to use this type of communication without changing the fundamental architecture of the system. 4) Dynamic software downloads would be slower due to the medium being used and while one TTD is downloading the image no other TTD could be accessing process B.

Figures 7A and 7B show a front view and rear view respectively of a TTD. The numerals in the figures denote, as follows: 1. Plastic Moulding

2. Red/Green/Orange LED

3. Track 2 Magnetic Swipe Reader

4. General Purpose Input/OUtput Port

5. Parallel Port 6. RS485 Port

7. External Floppy Drive Port

8. Power Connector 9. External Keyboard Port

10. Ethernet Connection

11. Speaker, and

12. Fan

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A table gaming management system, comprising: at least one table top device, a central control unit acting as a host to each table top device, each table top device and the control unit being connected in a server architecture configuration, wherein communication in the configuration is based on TCPIP protocol.

2. A system as claimed in claim 1 , wherein the server architecture is a host based transaction system in which each table top device functions to query or request information from a data storage means in the central unit.

3. A system as claimed in claim 2, further wherein the table to device sends information upon request to the central unit.

4. A system as claimed in claim 1 , wherein for each communication between the host and each table top device, a network socket is dynamically allocated.

5. A system as claimed in claim 4, wherein after the communication is finalised, the socket is closed.

6. A method of communicating between a central control unit and a table top device in a gaming system, the method comprising the step of using TCPIP protocol as a basis for such communication.

7. A method as claimed in claim 6, in which a table top device establishes communication with the central control unit by: communicating with the central control unit on a known port number, and having the central control unit allocate an ephemeral port number for the table top device to communicate on.