U.S. Pat. No. 8,861,521

DETAILED DESCRIPTION

In the following description the same reference designations will sometimes be used for elements having the same or similar functions.

Furthermore, in the figures of the following description connections between different entities are illustrated as separate logical connections. However, in reality the actual connections may be multiplexed on fewer inputs and outputs.

FIG. 1is a block diagram illustrating traditional multicasting in an online gaming system. A gaming domain10includes a number of game servers GS1, GS2, . . . , GSn. A typical gaming domain will include 3-7 game servers. Each game server is connected to a corresponding end-user set1,2, . . . , n. A typical end-user set may include 5000-15000 end-users. The union of all these sets form the gaming domain end-user set. During gaming sessions the game servers use these connections for individual communication with the end-users. It is to be noted that a specific game may involve end-users spread over several game servers (This is handled by interconnecting the game servers, as illustrated inFIG. 1.). However, the same connections are also used for multicasting messages to subsets of the gaming domain end-user set. The multicasting is managed by the game servers themselves, and typically involves several game servers, since an event triggering a message occurs on one game server and the end-users intended to receive the message may be spread over several game servers.

FIG. 2is a block diagram illustrating multicasting in an online gaming system in accordance with an embodiment of the present invention. To avoid cluttering of the figure, only two game servers GS1, GS2and a few end-users A-H have been drawn. However, as indicated above, the actual numbers (especially the number of end-users) are typically larger. The end-users are connected to the game servers for individual communication as inFIG. 1for gaming, but message multicasting will be handled by a separate system, as will be described below. In the example, game server GS1is assumed to manage the end-user set {A,D,E,F} and game server GS2is assumed to manage end-user set {B,C,G,H}. These “gaming connections” are not shown to avoid cluttering of the figure. The interconnection between the game servers has been omitted for the same reason.

In the embodiment illustrated inFIG. 2, messages from game servers GS1, GS2are not sent separately to each end-user recipient, as inFIG. 1. Instead they are sent only once to a multicast service system12, which distributes them to each end-user recipient. This multicast service system includes a number of interconnected multicast managers MM1, MM2, MM3receiving multicast messages, which are forwarded to multicast servers MS1, MS2, MS3, one for each multicast manager, which distribute them to the end-user recipient. When a multicast message is sent from one of the game servers GS1, GS2, it is received by one of the multicast managers MM1, MM2, MM3. This multicast manager will transfer the message to its associated multicast server for distribution to the end-user recipient connected to it. The end-user recipient that are not connected to this multicast server will be reached by sending the message to other multicast managers over the appropriate inter-connection lines L12, L13, L23for further distribution on the other multicast servers to the remaining end-user recipient. This process will be illustrated with reference toFIGS. 3 and 4.

In a preferred embodiment a load balancer LB is provided between the game servers and the multicast managers. The purpose of the load balancer is to avoid overloading of one of the multicast managers. In the example the load balancer may cycle through the multicast managers by sending a first message from one of the game servers to multicast manager MM1, a second message from one of the game servers to multicast manager MM2, a third message from one of the game servers to multicast manager MM3, and repeat this pattern for subsequent messages. Another possibility is to randomly send ⅓ (in average) of the received messages to each multicast manager.

FIG. 3is a block diagram illustrating multicasting of a specific message in the online gaming system ofFIG. 2. In this example game server GS1sends a message (represented by the envelope) to the end-user set {B,E,F}. This is accomplished by sending the actual message and an end-user recipient list {B,E,F} associated with this message to the multicast service system12. It is noted that end-user B is included in this list, although this end-user is actually managed by game server GS2. Thus, in this case the game associated with this message is spread over several servers, as described above. Although game server GS1does not manage end-user B, it may still include it in the end-user recipient list associated with the message.

The message with its end-user recipient list is received by one of the multicast managers, MM3in the example, preferably after passing through load balancer LB, which selects which multicast manager to use. The multicast manager MM3processes the end-user recipient list associated with the message to determine which end-user is associated with which multicast manager (or server, since they are paired together). In this case end-user F is associated with multicast manager MM3. Thus, multicast manager MM3sends the message as well as an end-user recipient sub-list {F} to multicast server MS3, which sends the message to end-user F. The multicast manager MM3also sends the message and an end-user recipient sub-list {B} to multicast manager MM1on interconnecting line L13, which forwards this information to multicast server MS1, which in turn sends the message to end-user B. Similarly, multicast manager MM3sends the message and an end-user recipient sub-list {E} to multicast manager MM2on interconnecting line L23, which forwards the information to multicast server MS2, which in turn sends the message to end-user E.

FIG. 4is a block diagram illustrating multicasting of another specific message in the online gaming system ofFIG. 2. In this case game server GS2sends a message to the end-user set {A,G,H} over multicast manager M1. Multicast manager MM1processes the end-user recipient list of the message to determine which end-user is associated with which multicast manager. In this case end-user A is associated with multicast manager MM1. Thus, multicast manager MM1sends the message as well as an end-user recipient sub-list {A} to multicast server MS1, which sends the message to end-user A. The multicast manager MM1also sends the message and an end-user recipient sub-list {G,H} to multicast manager MM3on interconnecting line L13, which forwards this information to multicast server MS3, which in turn distributes the message to end-users G and H. In this example multicast manager MM2is not used, since end-users D,E are not in the end-user recipient list.

It is also noted that end-users C and D did not receive any of the example messages inFIGS. 3 and 4. This is a further illustration of the multicasting feature that typically only proper subsets of the gaming domain end-user set will receive messages.

FIG. 5is a block diagram illustrating an embodiment of a multicast manager, for example multicast manager MM1inFIG. 2-4. A message and its associated end-user recipient list received by the multicast manager are forwarded to a recipient list extractor20, which extracts the list and forwards it to a recipient list processor22. This processor is connected to a memory24storing a table with the identities A-F of connected end-users and their associated multicast managers (or equivalently, their associated multicast servers). Recipient list processor22compares the recipients of the received end-user recipient list to the stored table and forms 3 end-user recipient sub-lists, which are forwarded (if not empty) to respective recipient list adders26,28,30, where they are added to the message and sent to multicast server MS1, multicast manager MM2and multicast manager MM3, respectively.

The functionality described with reference toFIG. 5is implemented in each multicast manager. In particular each multicast manager will include a copy of the table in memory24. The content this of table is updated as end-users are connected to and disconnected from the multicast servers.

Although the multicast managers and multicast servers have been illustrated as separate elements, they may also be integrated as a single unit.

In summary, the multicast service system described above will employ a multicast manager internally to keep track of which end-users that are connected to which multicast server. Each multicast manager is coupled to a single multicast server that manages the actual end-user communication. As an event is sent to the multicast service, it will be routed to a single multicast manager, preferably through a load balancer, for processing. The subsequent process can be described by the following steps:1. Iterate through the end-users recipient list.2. For each recipient, resolve which multicast server the end-user is connected to.3. Forward the messages to the associated multicast server together with the relevant recipient sub-list of end-users that are connected locally (unless the sub-list is empty).4. If there are remaining recipients connected to other multicast servers, build an end-user recipient sub-list for each of these multicast servers.5. Forward the message and each end-user recipient sub-list to the peer multicast manager(s).

In effect, this process will divide the distribution work among the available multicast servers and make sure that all recipient end-users are reached regardless of where they are connected.

The functionality of the multicast service system of the present invention is typically based on micro processor systems running corresponding software.

The scalability aspect of the present invention is similar to the solution commonly applied to solve the broadcasting problem described above. Servers are arranged in a tree structure where messages are distributed from the root (the source of messages) to the leaves (where end-users connect). Each leaf can only accept a limited number of end-user connections, but scalability can still be achieved by adding more leaves (multicast manager/server pairs). The main difference compared to the broadcast solution is that the multicast mechanism must also be able to send messages to a restricted set of end-users. This implies that the game server that initiates distribution of a multicast message must also provide a recipient list of end-users.

As described above, the present invention decouples the multicast mechanism from the game servers and introduces a new multicast service in a layer between the game servers and the end-users. This solution will keep the gaming logic clean from infrastructural concerns such as the transport mechanism(s) used to communicate with end-users. Furthermore it allows the multicast mechanism to scale as the number of receivers grows by fanning out the communication over several multicast manager/server pairs.

The multicast servers are responsible for managing the end-user connections. Apart from the actual distribution of messages this also means that the multicast servers abstract the transport mechanism used to communicate with the end-users. This effectively relieves the game servers from this responsibility and allows the game servers to manage all end-users in the same way regardless of whether the end-user is connected through a mobile phone, desktop client or is playing from the web.

Furthermore, the multicast servers can be designed and optimized for efficient IO performance without having to consider game logic as well. Consequently, the game servers can be optimized for rule processing capability. It should also be noted that the two types of servers; games servers and multi-cast servers, may now also scale separately. The number of game servers in use is relative to the amount of rule processing performance required. The number of multicast manager/server pairs in use is relative to the number of connected clients. The result is a more cost effective solution that consumes less hardware resources per end-user when scaling to meet the demands of a growing customer base.

It will be understood by those skilled in the art that various modifications and changes may be made to the present invention without departure from the scope thereof, which is defined by the appended claims.