Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/54—Interprogram communication
  • G06F9/547—Remote procedure calls [RPC]; Web services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/133—Protocols for remote procedure calls [RPC]
• • A—HUMAN NECESSITIES
  • A63—SPORTS; GAMES; AMUSEMENTS
  • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
  • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
  • A63F13/50—Controlling the output signals based on the game progress
  • A63F13/53—Controlling the output signals based on the game progress involving additional visual information provided to the game scene, e.g. by overlay to simulate a head-up display [HUD] or displaying a laser sight in a shooting game
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L49/00—Packet switching elements
  • H04L49/20—Support for services
  • H04L49/205—Quality of Service based
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/04—Protocols for data compression, e.g. ROHC

Definitions

• the present invention relates generally to communications between computing devices over a network and, more particularly, to an approach for efficient usage of network resources, particularly bandwidth, when a first computing device calls functions to be executed on a second computing device.
• IPTV IPTV
• Skype Skype
• the video game industry also has much to offer by harnessing the power of the Internet. As Internet connections become faster and more reliable, it becomes feasible to transmit larger amounts of graphics generated at a central source to participants in a video game. Moreover, because images are rendered in the "cloud", users can use ordinary PCs, tablets or smartphones to partake in the gaming experience, thus bypassing the need for expensive video game consoles. This is known as a cloud gaming system.
• a method for execution by a local device connectable to a remote device comprising:
• creating the packet comprises:
• the at least one instruction comprises an identifier of a function for execution by the remote device and a combination of parameters for use in execution of the function.
• creating the packet further comprises: when the determining is positive, formulating the packet so that it does not contain the identifier of the function or any of the parameters in the combination of parameters.
• the at least one instruction comprises at least one instruction for finding other players of the video game.
• the at least one instruction comprises at least one instruction for retrieving game news about the video game.
• creating the second packet comprises:
• the at least one first instruction comprises an identifier of a first function for execution by the remote device and a first combination of parameters for use in execution of the first function and wherein the at least one second instruction comprises an identifier of a second function for execution by the remote device and a second combination of parameters for use in execution of the second function.
• creating the second packet further comprises:
• creating the packet further comprises: when the second determining is positive, formulating the packet so that it does not contain any of the parameters.
• creating the packet further comprises: when the second determining is positive, formulating the packet so that it does not contain any of the parameters.
• creating the packet further comprises: when the second determining is positive:
• creating the packet further comprises: when the second determining is positive:
• creating the packet further comprises:
• creating the packet further comprises: when the determining is negative: formulating the packet so that it contains each of the one or more parameters.
• creating the packet further comprises: when the determining is negative:
• creating the packet further comprises: when the determining is negative:
• releasing the packet comprises placing the packet in an output queue of a communication unit.
• An apparatus connectable to a remote device comprising:
• a processing unit for creating a packet representing the at least one instruction and for releasing the packet via the interface towards the remote device;
• a memory comprising a shared packet dictionary;
• the processing unit is configured for:
• the at least one instruction comprises an identifier of a function for execution by the remote device and a combination of parameters for use in execution of the function.
• the processing unit is configured for determining whether the shared packet dictionary comprises an entry corresponding to the identifier of the function and the combination of parameters.
• the processing unit is further configured for:
• processing unit is further configured for running an application that issues the at least one instruction.
• the application comprises a video game and wherein the at least one instruction is rendering instruction for a game screen of the video game.
• the memory further comprise a parameter combination index table, wherein the determining is first determining, and wherein to create the packet, the processing unit is further configured for:
• the processing unit is further configured for:
• the processing unit is further configured for:
• the processing unit is further configured for:
• the processing unit is further configured for:
• the processing unit is further configured for:
• the processing unit is further configured for:
• the processing unit is further configured for:
• a second apparatus comprising: an interface for obtaining an identifier of at least one second instruction for execution by the remote device;
• a processing unit for creating a second packet representing the at least one second instruction and releasing the second packet via the interface towards the remote device;
• the processing unit is configured for: consulting the shared packet dictionary to second determine whether a packet index has already been assigned to the at least one second instruction;
• first instruction comprises an identifier of a first function and a first combination of parameters for use in execution of the first function and wherein the second instruction comprises an identifier of a second function and a second combination of parameters for use in execution of the second function.
• the processing entity of the first apparatus is further configured for:
• the processing entity of the second apparatus is further configured for:
• a non-transitory computer-readable medium storing instructions for execution by at least one processor of a local device, wherein execution of the instructions by the at least one processor of the local device causes the local device to implement a method that comprises:
• creating the packet comprises:
• a method for execution by a local device connectable to a remote device comprising:
• creating the packet comprises:
• creating the packet further comprises: when the determining is negative:
• An apparatus connectable to a remote device comprising:
• a processing unit for creating a packet representing the sequence of instructions and for releasing the packet via the interface towards the remote device;
• a memory comprising a sequence dictionary;
• the processing unit is configured for:
• a non-transitory computer-readable medium storing instructions for execution by at least one processor of a local device, wherein execution of the instructions by the at least one processor of the local device causes the local device to implement a method that comprises:
• creating the packet comprises:
• a method for execution by a second device connectable to a first device comprising:
• the method comprises determining from the packet dictionary, based on the packet index, a combination of parameter indexes associated with the combination of parameters and consulting a parameter index table on a basis of the parameter indexes in the combination of parameter indexes to determine the parameters in the combination of parameters.
• the method comprises determining from the packet dictionary, based on the packet index, at least one function index and consulting a function table on a basis of the function index to identify the function associated with the remote function call.
• a non-transitory computer-readable medium storing instructions for execution by at least one processor of a server, wherein execution of the instructions by the at least one processor of the server causes the server to implement a method that comprises:
• a method for execution by a second device connectable to a first device comprising:
• a method for execution by a second device connectable to a first device comprising: obtaining from the first device a packet comprising a sequence index associated with a sequence of instructions issued by the first device;
• a non-transitory computer-readable medium storing instructions for execution by at least one processor of a local device in an on-line gaming system, wherein execution of the instructions by the at least one processor of the local device causes implementation of:
• a game state management process for managing game state for a plurality of participants in a game
• a given one of the local stubs for obtaining commands issued by the game state management process, wherein upon obtaining a given one of the commands, a given one of the local stubs is configured to consult a packet dictionary shared among the plurality of local stubs in an attempt to find a packet identifier associated with the given instruction, and wherein upon a packet identifier being found, the given one of the local stubs is configured to release a packet containing the packet identifier towards a remote stub for remote execution of the given instruction at a device remote from the local device.
• a computing apparatus comprising:
• At least one processor for executing a game state management process to manage game state for a plurality of participants in a game
• a memory storing a packet dictionary
• the at least one processor implementing a plurality of local stubs for obtaining instructions issued by the game state management process, wherein upon obtaining a given set of instructions, a given one of the local stubs is configured to consult the packet dictionary shared among the plurality of local stubs in an attempt to find a packet identifier associated with the given set of instructions, and wherein upon a packet identifier being found, the given one of the local stubs is configured to release a packet containing the packet identifier towards the remote device via the interface for remote execution of the given set of instructions.
• a server system comprising:
• a game state server implementing a game state management process for at least one participant of a video game, the game state server adjusting a state of the video game based on input received over a network from at least one device associated with the at least one participant;
• a rendering server for rendering game screens for the at least one participant and for causing transmission of the game screens to the at least one participant over the network, the rendering server carrying out said rendering based on rendering commands that are compressed by the game state server, transmitted to the rendering server and decompressed by the rendering server.
• the game state server is configured for obtaining a set of rendering commands, consulting a packet dictionary in an attempt to determine whether a packet representing the set of rendering instructions has previously been transmitted to the rendering server and, when the attempt is successful, transmitting an index of the packet to the rendering server.
• Fig. 1 is a block diagram of a system including a central server and a rendering server, according to a non-limiting embodiment of the present invention
• Fig. 2 is a block diagram showing various functional modules of the central server, according to a non-limiting embodiment of the present invention
• Fig. 3 is a block diagram showing various functional modules of the rendering server, according to a non-limiting embodiment of the present invention
• Fig. 4 is a flowchart illustrating steps in a game state management process executed by the central server
• Fig. 5A illustrates a data structure for playing character input information that may be received from a client device
• Fig. 5B illustrates a data structure for a rendering instruction that may be issued by a game state management process being executed on the central server;
• Fig. 6 conceptually illustrates a remote procedure call and the functional entities involved therein, according to a non-limiting example embodiment
• Fig. 7 A is a flowchart representative of steps in a marshalling process, in accordance with a non-limiting embodiment of the present invention.
• Fig. 7B shows various mappings used in the marshalling process, including a function index table, a parameter index table and a packet dictionary, in accordance with a non- limiting embodiment of the present invention
• Fig. 7C shows a parameter combination index table that may be used in some non- limiting embodiments of the present invention.
• Fig. 7D is a variant of Fig. 7A in accordance with another non-limiting embodiment of the present invention.
• Fig. 8A conceptually illustrates the state of the function index table, the parameter index table and the packet dictionary, prior to processing a first of three example instructions, in accordance with a non-limiting embodiment of the present invention
• Fig. 8B conceptually illustrates the state of the function index table, the parameter index table and the packet dictionary, after processing the first instruction, as well as the resulting packet, in accordance with a non-limiting embodiment of the present invention
• Fig. 8C conceptually illustrates the state of the function index table, the parameter index table and the packet dictionary, after processing the second of three example instructions, as well as the resulting packet, in accordance with a non-limiting embodiment of the present invention
• Fig. 8D conceptually illustrates the packet resulting from processing the third of three example instructions, in accordance with a non-limiting embodiment of the present invention
• Fig. 9A is a flowchart representative of steps in an unmarshalling process, in accordance with a non-limiting embodiment of the present invention.
• Fig. 9B shows various mappings used in the unmarshalling process, including a function index table, a parameter index table and a packet dictionary, in accordance with a non-limiting embodiment of the present invention
• Fig. 9C shows a parameter combination index table that may be used in some non- limiting embodiments of the present invention.
• Fig. 9D is a variant of Fig. 9A in accordance with another non-limiting embodiment of the present invention.
• Fig. 10A conceptually illustrates the state of the function index table, the parameter index table and the packet dictionary, prior to processing a first received packet, in accordance with a non-limiting embodiment of the present invention
• Fig. 10B conceptually illustrates the state of the function index table, the parameter index table and the packet dictionary, after processing the first received packet, in accordance with a non-limiting embodiment of the present invention
• Fig. 10C conceptually illustrates the state of the function index table, the parameter index table and the packet dictionary, after processing the second received packet, in accordance with a non-limiting embodiment of the present invention
• Fig. 11A is a flowchart representative of steps in a marshalling process for handling sequences of instructions, in accordance with a non-limiting embodiment of the present invention.
• Fig. 11 B shows a sequence dictionary for use in the marshalling process of Fig. 11 A, in accordance with a non-limiting embodiment of the present invention
• Fig. 12A conceptually illustrates the state of the function index table, the parameter index table, the packet dictionary and the sequence dictionary, prior to processing a first of three example sequences of three instructions per sequence, in accordance with a non-limiting embodiment of the present invention
• Fig. 12B conceptually illustrates the state of the function index table, the parameter index table, the packet dictionary and the sequence dictionary, after processing the first example sequence of three instructions, as well as the resulting packet, in accordance with a non-limiting embodiment of the present invention
• Fig. 12C conceptually illustrates the state of the function index table, the parameter index table, the packet dictionary and the sequence dictionary, after processing the second example sequence of three instructions, as well as the resulting packet, in accordance with a non-limiting embodiment of the present invention
• Fig. 13 conceptually illustrates the packet resulting from processing the third of three example sequences of instructions, in accordance with a non-limiting embodiment of the present invention.
• Fig. 14A is a block diagram conceptually illustrating an architecture by virtue of which a plurality of local stubs implemented on a common device maintain sets of mappings for themselves independently;
• Fig. 14B is a block diagram conceptually illustrating an architecture by virtue of which a plurality of local stubs implemented on a common device share a common set of mappings;
• Fig. 15 is a block diagram conceptually illustrating an architecture by virtue of which a plurality of local stubs implemented on multiple devices share a common set of mappings.
• Fig. 1 shows a cloud computing architecture 10 according to an embodiment of the present invention.
• the cloud computing architecture 10 includes a server system for providing a service to one or more client devices 300a to 300e.
• the expression “the client device 300" refers to any or all of the client devices 300a to 300e unless otherwise specified.
• the cloud computing architecture 10 is a video game architecture and the "service" provided by the server system can be a single-player or a multi-player video game. It should be understood that a video game includes games that are played purely for entertainment as well as games played with the possibility of monetary gain (gambling).
• one or more of the client devices 300 can be, for example, a PC, home game machine (console such as XBOXTM, PS3TM, WiiTM), or portable game machine.
• one or more of the client devices 300 may be a communication or computing device such as a cell phone, PDA, or tablet (e.g., iPadTM).
• the client devices 300 have input devices, such as a touch screen, keyboard, game controller, joystick, etc., to allow users of the client devices 300 to provide input and participate in the game.
• the user of a given one of the client devices 300 may produce body motion or wave an external object; these movements are detected by a camera or other sensor (e.g., KinectTM), while software operating within the client device attempts to correctly guess whether the user intended to provide input to the client device and, if so, the nature of such input.
• a camera or other sensor e.g., KinectTM
• the server system comprises a central server 200 and a rendering server 100, although in other non-limiting embodiments, the server system can comprise one or more clusters of one or more servers per cluster.
• the servers in the server system such as the central server 200 and the rendering server 100, may communicate through a network 450 such as, for example, a dedicated private network, data center, or a virtual private network (VPN).
• the network 450 may ideally be a low-latency network.
• the central server 200 receives input signals 20 from the client devices 300a to 300e.
• the input signals 20 can be received from the various client devices 300a to 300e through a back channel over a network 400, such as a public data network (e.g., the Internet) or a private IP network.
• the input signals 20 can be the result of the client devices 300a to 300e detecting user actions, or they can be generated autonomously by the client devices 300a to 300e themselves.
• the input signal 20 from a given client device can convey that the user of the client device wishes to cause the character under his control to move, jump, kick, turn, swing, pull, grab, etc..
• the input signal 20 from a given client device can convey that the user of the client device wishes to select a particular camera view (e.g., first-person or third-person).
• the rendering server 100 is configured for rendering game screens for the client devices 300a to 300e, based on commands/instructions received from the central server 200. These commands can be transmitted from the central server 200 to the rendering server 100 in the form of packets 40 over the network 450.
• Output signals 30 containing the rendered game screens are distributed by the rendering server 100 to the client devices 300 over the network 400, such as the Internet.
• the networks 450, 400 may be possible to establish a low-latency, high-bandwidth channel between the central server 200 and the rendering server 100 over the network 400, in which case the networks 450, 400 could utilize the same physical resources.
• the networks 450, 400 are separate networks and traverse separate physical paths.
• a client device 300 need not have any rendering functionality for displaying a game screen. That is, each of the client devices 300 need only be an apparatus including a user interface for detecting input and comprising (or connectable to) a display device for displaying a received and rendered game screen. Since generating a game screen uses more hardware resources than those to be used by a process of decoding a video stream, the present system enables users to participate in a game independent of the rendering performance of a client device 300 by transmitting already-rendered game screens from the rendering server 100 to the client device 300. b. CENTRAL SERVER
• a central CPU 201 controls the operation of each module of the central server 200. More specifically, the CPU 201 reads out program instructions from, for example, a ROM 202 or central storage medium 204.
• the CPU 201 expands the program instructions into a central RAM 203 and executes the program, thereby carrying out a "game state management process" and controlling the operation of various other modules in the central server 200.
• the central ROM 202 can be, for example, a programmable non-volatile memory.
• the central ROM 202 stores program instructions for the game state management process, and may also store other program intructions.
• the central ROM 202 also stores information such as data required for the operation of each module of the central server 200.
• the central RAM 203 can be a volatile memory.
• the central RAM 203 is used not only as an expansion area for the game state management process operation program, but also as a storage area for temporarily storing, for example, intermediate data output during the operation of other modules of the central server 200.
• the central storage medium 204 can be, for example, a mass storage device such as an HDD detachable from the central server 200.
• the central storage medium 204 is used as, for example, a database for managing participants involved the game, and a database for managing various kinds of information on the game, which are required to generate a game screen to be provided for each participant in the game.
• the central communication unit 205 is a communication interface of the central server 200.
• the central communication unit 205 receives input signals 20 from the client devices 300 over the network 400.
• the central communication unit 205 also sends packets 40 to the rendering server 100 over the network 450.
• the central communication unit 205 may convert data into a data format complying with various communication specifications.
• RENDERING SERVER refers to both “players” and “spectators”, wherein “players” are typically assigned a character over which they exert some control during game play and “spectators” can typically view players' movements from a location of their choice without having control over game play.
• Fig. 3 is a block diagram showing various functional modules of the rendering server 100 according to a non-limiting embodiment of the present invention.
• a CPU 101 controls the operation of various modules of the rendering server 100. More specifically, the CPU 101 reads out program instructions stored in a ROM 102 or storage medium 104, expands the program instructions on a RAM 103, and executes the program, thereby carrying out a "rendering control process" and controlling the operation of each module.
• the ROM 102 is, for example, a programmable nonvolatile memory.
• the ROM 102 stores the program instructions for the rendering control process, other program instructions, and information such as data required for the operation of each module of the rendering server 100.
• the RAM 103 can be a volatile memory.
• the RAM 103 is used not only as an operation program expansion area, but also as a storage area for temporarily storing, for example, intermediate data output during the operation of each module of the rendering server 100.
• the storage medium 104 can be, for example, a mass storage device such as an HDD detachable from the rendering server 100.
• a communication unit 1 13 is a communication interface of the rendering server 100.
• the communication unit 1 13 exchanges data with other apparatuses.
• the communication unit 1 13 receives packets 40 from the central server 200 over the network 450.
• the communication unit 1 13 converts data received across the network 450 into an arbitrary data format readable by the rendering server 100, and temporarily stores the data in, for example, the RAM 103.
• the communication unit 1 13 sends rendered game screens to the client devices 300 over the network 400.
• the communication unit 1 13 converts the data into a data transmission format compatible with the network 400 or a transmission destination apparatus, and transmits the data to the transmission destination apparatus.
• GRAPHICS PROCESSING UNITS such as one of the client devices 300
• Game screens to be provided for the client devices 300 are generated by one or more graphics processing units (GPUs) 105 within or accessible to the rendering server 100.
• GPUs graphics processing units
• Each GPU 105 is connected to a video memory 109 (e.g., VRAM), which provides a rendering area for the game screen.
• VRAM video memory
• each GPU 105 expands an object in a cache memory (not shown), and writes the mapped object in the corresponding VRAM 109.
• one video memory 109 is connected to one GPU 105 in this embodiment, but the present invention is not limited to this. That is, the number of video memories 109 connected to the GPU 105 can be any arbitrary number.
• the rendering server 100 may be capable of simultaneously generating a plurality of game screens for a plurality of participants.
• the GPUs 105 are controlled by providing them with rendering instructions (also referred to as "rendering commands"). Interaction with the GPUs 105 can be achieved through a low-level API in order to draw triangles, lines, or points per frame, or to start highly parallel operations on the GPUs 105.
• the low-level API hides different GPU implementations behind a coherent abstraction.
• One non-limiting example of a low- level API is Direct3DTM, available from Microsoft Corporation of Redmond, Washington.
• supplying a rendering command to a GPU amounts to calling a function to be executed by the GPU.
• Examples of detailed data that may be part of a rendering command used to render a particular object may include one or more of: model data; texture data; the identity of a rendering program (for example, a shader) to be used; and data for calculations (for example, the light source intensity, light source vector, and rotation matrix) to be used by the rendering program.
• a rendering command may contain other information used in the process of rendering an object.
• the rendering of a game screen for a particular participant may require the execution of hundreds or thousands of rendering instructions.
• the game screen is provided by the rendering server 100 to the client device 300 associated with the particular participant.
• the system 10 of the present embodiment can generate game screens corresponding to inputs provided at the various client devices 300 at a rate of several times (e.g., 30 or 60) per second for each participant. These game screens are displayed to the corresponding participants via the display device of each participant's client device 300. At this rate, the human eye will perceive fluidity of motion.
• the system 10 of the present non-limiting embodiment includes one rendering server 100 and one central server 200
• the present invention is not limited to this specific arrangement.
• the central server 200 can also designate a rendering server 100 or a GPU of a rendering server 100 to be used to execute a rendering instruction, in accordance with information indicating the number of game screens simultaneously generated by a rendering server 100 or each GPU of a rendering server 100.
• the game state management process for a given participant is spawned when that participant's client device 300 connects to the central server 200.
• the game state management process for the given participant includes a main loop that is executed for each frame, namely several (e.g., 30 or 60) times per second.
• the central server 200 receives participant input 30 via the client devices 300 (step S401 ), modifies game state information (step S403), determines the objects in the "game screen" for the given participant (S404) and generates function calls to the GPUs 105 (step S405). This is now described in greater detail.
• the central server 200 manages information pertaining to characters operated by the players (such as their position and direction on a map) and also manages events associated with each character and with the game as a whole. For example, when a given player provides an input to his or her client device 300, this information is transmitted across the network 400 to the central server 200 which, in executing the game state management process, updates the information pertaining to the given player's character. Also as part of the game state management process, the central server 200 causes the rendering server 100 to generate a game screen for each participant. Specifically, the central server 200 determines one or more objects to be rendered on the game screen for each participant, and transmits a set of rendering instructions (possibly thousands per frame) to the rendering server 100.
• step S401 input information may be received from the client device 300 associated with the given participant or from the client device 300 associated with one or more other players or spectators.
• the input information may indicate that the players or spectators have carried out an operation on their characters via their client device.
• the input information may have a data structure, a non-limiting example of which is shown in Fig. 5A.
• the data structure may contain one or more of: an identifier (for example, an IP address and user identification information) of a client device at which an operation by a player or spectator has been carried out; movement information, including magnitude and direction; identification information of a selected action; rendering range of a game screen (for example, a camera parameter); and/or the display setting (for example, the screen display resolution and the number of colors) of the display device connected to the client device.
• an identifier for example, an IP address and user identification information
• movement information including magnitude and direction
• identification information of a selected action for example, rendering range of a game screen (for example, a camera parameter)
• rendering range of a game screen for example, a camera parameter
• the display setting for example, the screen display resolution and the number of colors
• the input information can be a set of numerical values obtained by converting an operation effected on the client device 300 by the player or spectator into numerical values/parameters.
• the input information may include an input signal detected by the client device 300 (e.g., in response to pressing a button or the like by the player or spectator), in which case the process of conversion into numerical values/parameters can be performed by the central CPU 201 , as a function of the type of client device 300 from which it was received.
• an update to the playing characters, non-playing characters and other graphical elements is performed.
• Examples of other graphical elements include background objects such as a landform.
• the objects to be rendered can change with time in accordance with game rules, or by the action of a character as controlled by the corresponding player.
• the central CPU 201 reads out, from the central storage medium 204, state information corresponding to each character or graphical element in the game that was affected by the input information, clock information or other information.
• state information this may include information pertaining to the appearance and properties of a character that can be changed by a player's operation, such as, for example, the position (coordinate information) of the character on the map, the gazing direction of the character, and the character's action.
• a parameter pertaining to the character is updated. Accordingly, the actions carried out by the players can be reflected on the characters in the game.
• the game screen rendering range can include a set of coordinates (e.g., in two or in three dimensions) that delimits the set of objects contained in the game screen for that participant.
• the objects contained in the game screen for a given participant will vary from one participant to the next.
• the central CPU 201 reads out, from the central storage medium 204, the game screen rendering range for the given participant's client device 300.
• the game screen rendering range contains, e.g., camera parameters corresponding to the game screen.
• the central CPU 201 refers to the camera parameters, and specifies, as a rendering object contained in the game screen, a rendering object such as a character whose state information contains coordinate information included in the camera's rendering range.
• an identifier is assigned to each object to be rendered, and the central CPU 201 associates the object identifier with the client device identifier, and records the information on the central storage medium 204.
• the game state management process generates rendering instructions for rendering the objects in the given participant's game screen.
• the rendering instructions issued by the game state management process for a particular client device 300 may include one or more of: an identifier of each object contained in the game screen; detailed information regarding each object contained in the game screen; state information regarding each object contained in the game screen; and information regarding the rendering range and display setting of the game screen.
• the game is, for example, a game in which the camera position remains unchanged or a game having a fixed display resolution
• information such as the camera parameters and display setting indicating the game screen rendering range need not be contained in the rendering instruction.
• the rendering instructions generated at step S405 of the game state management process executed by the CPU 201 of the central server 200 are issued as function calls destined for one or more of the GPUs 105, which are on the rendering server 100.
• This can be achieved by virtue of remote procedure calls, whereby a local device (the central server 200) calls one or more functions at a remote device (the rendering server 100).
• Such remote procedure calls are carried out several hundred or thousand times per frame, for each of the client devices 300.
• Fig. 6 conceptually illustrates a remote procedure call and the functional entities involved therein, according to a non-limiting example embodiment.
• a local stub 620 which can be embodied as a software routine / procedure that is invoked either implicitly or explicitly by the game state management process upon issuing one or more rendering instructions 610.
• the game state management process may operate at a first level of the OS I model (e.g., the application layer)
• the local stub 620 may operate at a lower level of the OSI model (e.g., the presentation layer).
• the local stub 620 can be invoked by operating system.
• the local stub 620 assembles the data associated with the one or more rendering instructions 610 into a packet 630 and makes a low-level system call to send the packet 630. Assembling the data associated with the rendering instructions into the packet 630 is called "marshalling", and will be described in further detail later on.
• the operating system of the central server 200 releases the packet 630 from the central server 200 (which can be viewed as the "local” device) into the network 450 towards the rendering server 100 (which can be viewed as the "remote: device).
• the operating system of the rendering server 100 passes the incoming packet 640 (whose contents may be identical to those of packet 630) to a remote stub 650, which is part of the rendering control process running on the CPU 101 .
• the remote stub 650 disassembles the parameters from the packet 640. Disassembly of the parameters is called "unmarshalling", and will be described in further detail later on. This results in the one or more rendering instructions 630 being reconstructed.
• the remote stub 650 sends the rendering instructions to the
• the rendering control process sends the rendered game screen to the client device 300 corresponding to that participant.
• the game screen may comprise a frame of video, which can be encoded into a suitable format for delivery to the client device 300 over the network 400.
• the video frame may also include audio as well as other information including control information.
• the remote procedure calls can be made more efficient by compressing or condensing them.
• the local stub 620 can be specially adapted to carry out a marshalling process that leads to the generation of condensed packets 40.
• the remote stub 650 can be specially adapted to carry out a unmarshalling process for expanding received packets that have been condensed. g. MARSHALLING
• the local stub 620 in the central server 200 executes a marshalling process.
• a marshalling process an instruction to be executed by the remote device is obtained.
• a packet representing the instruction is created and released towards the remote device. Creation of the packet involves consulting a memory to determine whether a "packet index" has already been assigned to the instruction. If this is the case, the packet is formulated so that it contains the packet index. Since fewer bits are needed to encode the packet index than to encode the instruction, the packets generated by the marshalling process will have a tendency to be condensed when they repeatedly represent the same instruction.
• Fig. 7A shows a flowchart representative of steps in a marshalling process for generating condensed packets to be sent to a remote device, in accordance with a non-limiting embodiment of the present invention.
• an instruction is received.
• the instruction may be a rendering instruction issued by a game state management process at the application layer.
• the instruction can be formatted in numerous ways.
• the instruction may be formatted as a function call, such as:
• the instruction includes at least a "function identifier"
• the function identifier represents a function to be executed remotely by the remote device (e.g., the rendering server 100).
• the function identifier (Functioncall) is considered to be condensable, which means that the marshalling process will favor using a function index, rather than the function identifier, to encode the function to be executed by the remote device. This will result in fewer bits being used to encode the same function.
• the instruction can also include function arguments (e.g., Data) that are not considered to be condensable.
• function arguments e.g., Data
• the demarcation between function arguments that are considered to be condensable those which are not considered to be condensable may be different in different embodiments. For example, in some embodiments, the values acquired by pointers, addresses and variables are considered to be condensable, whereas in other embodiments, these same values would not considered incondensable.
• a function index table 790 and a parameter index table 792 associates function identifiers with respective function indexes, and is accessed on the basis of a received function identifier.
• the parameter index table 792 associates parameters with respective parameter indexes, and is accessed on the basis of a received parameter.
• a packet dictionary 794 associates specific function calls involving specific combinations of parameters to respective packet indexes. That is to say, each entry in the packet dictionary 794 associates a function identifier and a combination of parameters to a particular packet index. There may be a maximum number of parameters N in a combination of parameters that may be listed in the packet dictionary 794.
• the function index table 790, the parameter index table 792 and the packet dictionary 794 may be implemented as databases that are maintained in the central RAM 203 or the central storage medium 204.
• the function index table 790, the parameter index table 792 and the packet dictionary 794 can be maintained on external storage, which is accessible to the central server 200 via a local storage area network (SAN), the network 450 or the network 400. Still other possibilities will be apparent to those of skill in the art.
• SAN local storage area network
• the packet dictionary 794 is checked.
• the current set of function identifier and combination (i.e., ordered set) of parameters is compared against the entries of the packet dictionary 794 to determine whether the packet dictionary 794 includes a packet index for the current set of function identifier and combination of parameters. If the answer is affirmative, this will indicate that a packet representing the same function and the same combination has already been created and transmitted to the remote device (e.g., the rendering serve 100).
• the marshalling process proceeds to step S740, wherein the existing packet index is retrieved from the packet dictionary 794, and a packet is formulated such that it includes the packet index.
• function arguments e.g., certain forms of data
• that are not considered to be condensable may be appended to the packet.
• step S750 wherein the newly created packet is transmitted to the remote device (e.g., the rendering server 100) over the network 450.
• the packet also includes any necessary header or other information that would make it suitable for transmission over the network 450.
• the packet may be formatted in such a way as to alert the remote device that it carries a packet index rather than the function identifier or the parameters themselves.
• step S760 the function index table 790 and the parameter index table 792 are checked. In particular, it is determined whether the function index table 790 includes a function index for the function identifier. If the answer is affirmative, this will indicate that the same function has been called in the past, although with different parameters (or with the same parameters but in a different order). It is also determined whether the parameter index table 792 includes a parameter index for one or more of the parameters. If the answer is affirmative for a given parameter, this will indicate that the given parameter has been part of a function call in the past. Accordingly, at step S765, the previously assigned/allocated function index and/or parameter index(es) is(are) retrieved.
• step S770 a packet is formulated such that it includes any previously assigned function index and/or parameter index(es) that was(were) retrieved at step S765.
• function arguments that are not considered to be condensable may be appended to the packet.
• step S765 If there was no function index retrieved at step S765, then the complete function identifier is used in the packet.
• a step S775 an entry for the function identifier is created in the function index table 790 and a function index is assigned to the function identifier and stored in association therewith. Assignment of the function index to the function identifier may proceed in accordance with a function index assignment algorithm that is known to both the local device and the remote device. If this is the case, then it is not necessary to inform the remote device of the function index assigned to the function identifier, because the remote device can derive the function index by executing the same function index assignment algorithm as the local device. However, if the function index assignment algorithm is not known to both the local device and the remote device, then it may be desirable to include, in the packet, not only the complete function identifier, but also the function index associated therewith.
• the complete parameter is used in the packet.
• an entry for each such parameter is created in the parameter index table 792 and a parameter index is assigned to the parameter and stored in association therewith.
• Assignment of parameter indexes to parameters may proceed in accordance with a parameter index assignment algorithm that is known to both the local device and the remote device. If this is the case, then it is not necessary to inform the remote device of the parameter index assigned to a given parameter, because the remote device can derive the parameter index by executing the same parameter index assignment algorithm as the local device. However, if the parameter index assignment algorithm is not known to the remote device, then when including a complete parameter in the packet, it may also be desirable to include the parameter index associated therewith.
• the marshalling process further executes step S750, wherein the packet is transmitted to the remote device (e.g., the rendering server 100) over the network 450. This can be done by placing the packet in an output queue of the central communication unit 205.
• the packet also includes any necessary header or other information that would make the packet suitable for transmission over the network 450.
• Fig. 8A shows the status of the packet dictionary 794, the function index table 790 and the parameter index table 792 prior to receipt or processing of the first instruction
• the first iteration of the marshalling process begins at step S710, whereby the first instruction Functioncaii i (Parami, Param2, Param3) is received.
• the function identifier is Functioncaii i and the combination (ordered set) of parameters is Parami, Param2, Param3.
• the packet dictionary 794 is consulted at step S720, and it is determined that there is no entry in the packet dictionary 794 for the current function identifier (Functioncaii i) and the current combination of parameters (Parami, Param2, Param3).
• the function index table 790 and the parameter index table 792 are checked.
• step S770 This results in the creation of a packet which, as illustrated in Fig. 8B, is denoted 810 includes function identifier Functioncaii i and parameters Parami, Param2 and Param3, the order of which is preserved.
• step S775 which may be executed before, during or after step S770, an entry 812 is created in the function index table 790 for function identifier Functioncaii_i, and a function index 0x1 is assigned to function identifier Functioncaii i and stored in the newly created entry 812.
• three entries 814, 816, 818 are created in the parameter index table 792, one each for Parami, Param2 and Param3, and parameter indexes 0x1 , 0x2 and 0x3 are assigned to parameters Parami, Param2 and Param3 and stored in the respective newly created entries 814, 816, 818.
• step S780 which may also be executed before, during or after step S770, a new entry 820 is created in the packet dictionary 794 for the function identifier Functioncaii i together with the combination of parameters Parami, Param2, Param3, to which a packet index 0x1 is assigned.
• packet 810 is released towards the remote device.
• packet index 0x1 may be included in packet 810, while function index 0x1 may accompany function identifier Functioncaii i and parameter indexes 0x1 , 0x2 and 0x3 may accompany parameters Parami , Param2 and Param3 in packet 810.
• Providing this additional information may assist the remote device in replicating its own versions of the packet dictionary 794, the function index table 790 and the parameter index table 792, particularly when the remote device is not aware of the algorithm/process used by the local device to generate the packet index, the function index and the parameter indexes.
• the second iteration of the marshalling process begins at step S710, whereby the second instruction Functioncaii_2 (Param3, Param4) is received.
• the function identifier is Functioncaii_2 and the combination (ordered set) of parameters is Param3, Param4.
• the packet dictionary 794 is consulted at step S720, and it is determined that there is no entry in the packet dictionary 794 for the current function identifier and combination of parameters.
• the function index table 790 and the parameter index table 792 are checked.
• the function index table 790 does not include an entry for function identifier Functioncaii_2.
• the parameter index table 792 does not include an entry for parameter Param4, it does include and entry for parameter Param3. Accordingly, the marshalling process proceeds to step 765, where parameter index 0x3 is retrieved in association with parameter Param3.
• step S770 the marshalling process continues to step S770, where a packet 830 is created, and includes function identifier Functioncaii_2, parameter index 0x3 (in lieu of parameter Param3) and parameter Param4.
• a flag may be inserted into packet 830 in order to differentiate between fields that convey a parameter versus fields that convey a parameter index.
• step S775 which may be executed before, during or after step S770, an entry 832 is created in the function index table 790 for function identifier Functioncaii_2, and a function index 0x2 is assigned to function identifier Functioncaii_2 and stored in the newly created entry 832.
• an entry 834 is created in the parameter index table 792 for Param4, and parameter index 0x4 is assigned thereto and stored in the newly created entry 834.
• a new entry 836 is created in the packet dictionary 794 for the function identifier Functioncaii_2 together with the combination of parameters Param3, Param4, to which a packet index 0x2 is assigned.
• packet 830 is released towards the remote device.
• packet index 0x2 may be included in packet 830, while function index 0x2 may accompany function identifier Functioncaii_2 and parameter index 0x4 may accompany parameter Param4 in packet 830. This additional information may assist the remote device in replicating its own versions of the packet dictionary 794, the function index table 790 and the parameter index table 792.
• packet 830 includes parameter index 0x3 instead of parameter Param3, packet 830 is shorter in length than it would have been, had it included parameter Param3 in fully expanded (uncondensed) form. That is to say, packet 830 is condensed, which means that it takes less time to transmit and consumes less bandwidth through the network 450. Transmission efficiency thus increases as a result of the present marshalling process.
• step S720 Functioncaii i and the combination (ordered lit) of parameters is Paraml, Param2, Param3.
• the packet dictionary 794 is consulted at step S720.
• entry 812 which associates packet index 0x1 with function identifier Functioncaii i and the
• step S740 packet index 0x1 is retrieved, resulting in the creation of a packet 840 (see Fig. 8D) that includes packet index 0x1 .
• packet 840 is released towards the remote device.
• a flag may be inserted into packet 840 in order to signal that what is being conveyed by packet 40 is a packet index rather than a function identifier, function index, parameter or parameter index.
• packet 840 includes packet index 0x1 instead of function identifier Functioncaii i ⁇ any Of the parameters Parami, Param2, Param3— or even any of the parameter indexes 0x1 , 0x2, 0x3— packet 840 is shorter in length than it would have been, had it included the aforementioned information. That is to say, packet 840 is condensed, which means that it takes less time to transmit and consumes less bandwidth through the network 450. Transmission efficiency thus increases as a result of the present marshalling process.
• a parameter combination index table 796 may be provided.
• the parameter combination index table 796 associates combinations of parameters to respective parameter combination indexes. That is to say, each entry in the parameter combination index table 796 associates an ordered set of parameters to a particular code (a "parameter combination index").
• the parameter combination index table 796 may be implemented as a database that is maintained in the central RAM 203 or the central storage medium 204.
• the parameter combination index table 796 can be maintained on external storage, which is accessible to the central server 200 via a local storage area network (SAN), the network 450 or the network 400.
• SAN local storage area network
• step S760 In order for the marshalling process to make use of the parameter combination index table 796, a modification is made to step S760. Specifically, step S760 would be modified so as to check the function index table 790 and the parameter combination index table 796. In this way, not only will it be determined that the function index table 790 includes a function index for the function identifier if it has already been called in the past, but also it will be determined that the parameter combination index table 790 includes a parameter combination index if the current combination of parameters has been called in the past, albeit using a different function. Accordingly, at step S765, the available function index and/or parameter combination index would be retrieved.
• step S775 would be modified so that if it is determined that there was no entry in the parameter combination index table 796 at step S760, a new entry for the current combination of parameters would be created in the parameter combination index table 796, and a parameter combination index would be assigned to this combination of parameters and stored in association therewith. Assignment of the parameter combination index to the current combination of parameters may proceed in accordance with a parameter combination index assignment algorithm that is known to both the local device and remote devices.
• the remote device can derive the parameter combination index by executing the same parameter combination index assignment algorithm in parallel.
• the parameter combination index assignment algorithm is not known to the remote device, then it may be desirable to include, in the transmitted packet, the parameter combination index associated with the current combination of parameters.
• the instruction issued by the game state management process and received by the local stub 620 may include a generic function identifier, while the specifics of the function can be partly embedded amongst the parameters. For example, consider the following sequence of instructions:
• the function identifier is the same (i.e., Functioncall), the actual function being called is different and takes the form of a function argument.
• the "combination of parameters" includes at least one parameter that specifies the nature of the function being called.
• the function identifier is considered to be no different from any other parameter.
• step S760D includes consideration of the parameter index table 792 but does not include consideration of a "function index table”. Also, reference to a "function index" has been omitted in steps S770D and S775D.
• an unmarshalling process is executed on packets received over the network 450.
• the unmarshalling process can be carried out by the remote stub 650 in the rendering server 100, although it is to be understood that the unmarshalling process can be carried out by any entity that receives packets that have been marshaled as previously described with reference to Fig. 7A.
• the remote device e.g., the rendering server 100
• these entities will be similar to the function index table 790, the parameter index table 792 and the packet dictionary 794 maintained by the local device (e.g., the central server 200).
• the entries in the function index table 990, the parameter index table 992 and the packet dictionary 994 are accessed differently.
• the function index table 990 which associates function indexes with respective function identifiers, is accessed on the basis of a received function index
• the parameter index table 992 which associates parameter indexes with respective parameters, is accessed on the basis of a received parameter index
• the packet dictionary 994 which associates each of a plurality of packet indexes to a specific function identifier and combination of parameters, is accessed on the basis of a received packet index.
• the function index table 990, the parameter index table 992 and the packet dictionary 994 may be implemented as databases that are maintained in the RAM 103 or the storage medium 104 of the rendering server 100.
• the function index table 990, the parameter index table 992 and the packet dictionary 994 can be maintained on external storage, which is accessible to the rendering server 100 via a local storage area network (SAN) , the network 450 or the network 400.
• SAN local storage area network
• a packet is received.
• the packet can be received over the network 450 from the local device (e.g., the central server 200), which instantiates the local stub 620 responsible for creating the packet.
• the presence of a packet index in a received packet signals that an identical packet (i.e., representing the same function and parameters) has previously been created by the local device and transmitted to the remote device.
• step S910 if step S910 reveals that the received packet includes a packet index, the unmarshalling process proceeds to step S920, where the packet dictionary 994 is consulted on the basis of the packet index. In this manner, a corresponding function identifier and combination of parameters are obtained from the packet dictionary 994, and the unmarshalling process proceeds to step S930.
• the function identified by the function identifier is called locally on the remote device, using the retrieved parameters (in the appropriate combination) as arguments.
• a game screen can be rendered by the rendering server 100. The rendered game screen can be distributed to the central server 200 (via a remote procedure call in the opposite direction) or directly to the participant for which the rendering instruction was carried out.
• step S940 if the received packet does not include a packet index, then this signals that the received packet was not previously received, and the unmarshalling process proceeds to step S940.
• a series of tests can be conducted, in no particular required order. These tests may also be conducted in parallel. Firstly, it can be verified whether the received packet includes either a function index or a function identifier. In the case where the received packet includes a function index, the unmarshalling process proceeds to step S942, where the function index table 990 is consulted on the basis of the function index. In this manner, a corresponding function identifier is obtained from the function index table 990.
• the unmarshalling process proceeds to step S944, where a function index is assigned to the function identifier, and an entry is created in the function index table 990, which associates the function index and the function identifier.
• Assignment of the function index to the function identifier may proceed in accordance with a function index assignment algorithm that is assumed to have been used by the local device during execution of the marshalling process.
• step S950 it can be verified whether the received packet includes one or more parameter indexes.
• the unmarshalling process proceeds to step S952, where the parameter index table 992 is consulted on the basis of the parameter index or indexes. As a result, corresponding parameters (or possibly a single corresponding parameter) are retrieved from the parameter index table 992.
• step S954 it can be verified whether the received packet includes one or more parameters, rather than parameter indexes.
• the unmarshalling process proceeds to step S956, where a parameter index is assigned to each such parameter, and an entry is created in the parameter index table 992 for each such parameter, thereby associating each such parameter with its newly assigned parameter index. Assignment of parameter indexes to parameters may proceed in accordance with a parameter index assignment algorithm that is assumed to have been used by the local device during execution of the marshalling process.
• a packet index is assigned to the function identifier and combination of parameters that were either included in the received packet or were retrieved from the function index table 992 and/or the parameter index table 994. Assignment of the packet index to the function identifier and combination of parameters may proceed in accordance with a packet index assignment algorithm that is assumed to have been used by the local device during execution of the marshalling process.
• S910) includes a packet index, it does not include the corresponding function identifier or combination of parameters, and vice versa.
• the presence of a packet index in a received packet signals that the very same packet has previously been received.
• the packet dictionary 994 has already been populated with that very same packet index.
• the packet dictionary 994 has already been populated with that very same packet index.
• the packet dictionary 994 will associate the received packet index with the received set of function identifier and combination of parameters.
• packets 810, 830 and 840 which were sent from the local device to the remote device, include the following information:
• Fig. 10A shows the status of the packet dictionary 994, the function index table 990 and the parameter index table 992 prior to receipt or processing of packet 810. Quite simply, the packet dictionary 994, the function index table 990 and the parameter index table 992 are all empty.
• Step S910 the first iteration of the unmarshalling process begins at step S910, whereby packet 810 is received.
• the function identifier is Functioncaii i and the combination (ordered set) of parameters is Parami, Param2, Param3.
• Step S920 reveals that there is no packet index included with packet 810 and therefore the unmarshalling process proceeds to step S940.
• step S940 it is checked whether packet 810 specifies a function identifier or a function index. Since packet 810 specifies function identifier Functioncaii i, and thus, with additional reference to Fig. 10B, the unmarshalling process proceeds to step S944, whereby an entry 1012 is created in the function index table 990 for function identifier Functioncaii_i, and a function index 0x1 is assigned to function identifier Functioncaii i (using the same algorithm as in the marshalling process) and stored in the newly created entry 1012.
• step S950 it is checked whether packet 810 includes at least one parameter index. Since packet 810 only includes parameters and no parameter indexes, the unmarshalling process proceeds to step S954. At step S954, it is checked whether packet 810 includes at least one parameter. Since this is indeed the case, the unmarshalling process proceeds to step S956, whereby three new entries 1014, 1016, 1018 are created in the parameter index table 992, one each for Parami, Param2 and Param3, and parameter indexes 0x1 , 0x2 and 0x3 are assigned to parameters Parami, Param2 and Param3 (using the same algorithm as in the marshalling process) and stored in the respective newly created entries 1014, 1016, 1018.
• a new entry 1020 is created in the packet dictionary 994 for the function identifier Functioncaii i together with the combination of parameters Parami, Param2, Param3, to which a packet index 0x1 is assigned (using the same algorithm as in the marshalling process).
• the function identified by the function identifier Functioncaii i is called, using the parameters Parami, Param2, Param3 as arguments.
• a game screen can be rendered by the rendering server 100.
• the rendered game screen can be distributed to the central server 200 (via a remote procedure call in the opposite direction) or directly to the participant for which the rendering instruction was carried out.
• the present invention is not limited to rendering instructions or a gaming environment.
• step S910 The second iteration of the unmarshalling process begins at step S910, whereby packet 830 is received.
• the function identifier is Functioncaii_2, which is received together with parameter index 0x3 and parameter Param4.
• Step S920 reveals that there is no packet index included with packet 830 and therefore the unmarshalling process proceeds to step S940.
• step S940 it is checked whether packet 830 specifies a function identifier or a function index. Since packet 830 specifies function identifier Functioncaii_2, and with additional reference to Fig. 10C, the unmarshalling process proceeds to step S944, whereby an entry 1032 is created in the function index table 990 for function identifier Functioncaii_2, and a function index 0x2 is assigned to function identifier Functioncaii_i (using the same algorithm as in the marshalling process) and stored in the newly created entry 1032.
• step S950 it is checked whether packet 830 includes at least one parameter index. Since packet 830 includes only parameter index 0x3, the unmarshalling process proceeds to step S952, where the parameters associated with parameter index 0x3 are retrieved from the parameter index table 992. In particular, it will be recalled that execution of step S956 in connection with unmarshalling of packet 810 resulted parameter index 0x3 having been assigned to Param3. Therefore, during current execution of step S952, the parameter Param3 is retrieved.
• step S954 it is checked whether packet 830 at least one parameter. Since this is indeed the case (namely, packet 830 includes parameter Param4), the unmarshalling process proceeds to step S956, whereby a new entry 1034 is created in the parameter index table 992 for Param4. In this case, parameter index 0x4 is assigned to parameter Param4 using the same algorithm as in the marshalling process, and parameter index 0x4 is stored in the newly created entry 1034.
• a new entry 1036 is created in the packet dictionary 994 for the function identifier Functioncaii_2 together with the combination of parameters Param3, Param4, to which a packet index 0x2 is assigned (using the same algorithm as in the marshalling process).
• a game screen can be rendered by the rendering server 100.
• the rendered game screen can be distributed to the central server 200 (via a remote procedure call in the opposite direction) or directly to the participant for which the rendering instruction was carried out.
• the present invention is not limited to rendering instructions or a gaming environment.
• step S910 The third iteration of the unmarshalling process begins at step S910, whereby packet 840 is received. Packet 840 includes packet index 0x1 . Since step S920 will reveal that there is a packet index included with packet 840, the unmarshalling process proceeds to step S920.
• the function identifier and the parameters associated with packet index 0x1 are retrieved from the packet dictionary 994.
• the retrieved function identifier will be Functioncaii i and the retreieved combination of parameters will be
• a game screen can be rendered by the rendering server 100.
• the rendered game screen can be distributed to the central server 200 (via a remote procedure call in the opposite direction) or directly to the participant for which the rendering instruction was carried out.
• the present invention is not limited to rendering instructions or a gaming environment.
• packets 810 and 840 result in execution of the same function with the same parameters, the amount of network resources (bandwidth) required to transmit packet 840 is less than the amount of network resources required to transmit packet 810.
• a parameter combination index table 996 may be provided.
• the parameter combination index table 996 associates parameter combination indexes with respective combinations of parameters. That is to say, each entry in the parameter combination index table 996 associates an ordered set of parameters to a particular code (referred to as a parameter combination index).
• the parameter combination index table 996 may be implemented as a database that is maintained in the RAM 103 or the storage medium 104 of the rendering server 100.
• the parameter combination index table 996 can be maintained on external storage, which is accessible to the rendering 100 via a local storage area network (SAN), the network 450 or the network 400.
• SAN local storage area network
• a modification is made to the unmarshalling process. Specifically, with reference to Fig. 9D, a new step S946 is introduced, where it would be checked whether the received packet includes a parameter combination index. In the affirmative, the corresponding combination of parameters would be retrieved from the parameter combination index table 996 at step S948, and the unmarshalling process would then rejoin the unmarshalling process of Fig. 9A at step S958. However, if the received packet was found not to include a parameter combination index, the unmarshalling process proceeds to execute steps S950 through S956 as previously described.
• a new step S957 would be provided, whereby a new entry would be created in the parameter combination index table 996, and a parameter combination index would be assigned to the current combination of parameters and stored in association therewith. Assignment of the parameter combination index to the current combination of parameters may proceed in accordance with the same parameter combination index assignment algorithm that was used by the local device.
• the function identifier may in fact be one of the parameters.
• the "combination of parameters" includes at least one parameter that specifies the nature of the function being called.
• the function index table 990 is effectively subsumed into the parameter index table 992.
• steps S940, S942 and S944 from the flowchart in Fig. 9A can effectively be omitted.
• the marshalling process for condensing sequences of received instructions may be represented by a flowchart illustrated in Fig. 1 1 A.
• the marshalling process may be executed by the local stub 620 in the central server 200, although the presently described process can be applied wherever remote procedure calls are used.
• an instruction is received.
• the instruction may be a rendering instruction issued by a game state management process at the application layer.
• it is verified whether the received instruction completes a sequence of instructions, so as to proceed with consulting a sequence dictionary at step S1 130.
• This can be determined in a number of ways. For example, the marshalling process may consider that a fixed number of received instructions form a sequence. In another embodiment, the marshalling process may wait until several instructions are received and may process them to detect patterns therein and then begin processing the instructions in the oldest (least recent) sequence in accordance with the knowledge that there will be some repetition and therefore efficiency gain. Other methodologies for determining whether a sequence has been completed will be understood as being within the scope of the present invention.
• a sequence dictionary 1 190 comprises entries that associate sequence indexes with respective sequences of instructions.
• Each instruction represented in a given sequence of instructions may be associated with a respective function identifier and a respective combination of parameters.
• each entry in the sequence dictionary 1 190 associates a sequence index with a sequence of function identifiers and respective combinations of parameters.
• the sequence dictionary 1 190 may be implemented as a database that is maintained in the central RAM 203 or the central storage medium 204. In another non-limiting embodiment, the sequence dictionary 1 190 can be maintained on external storage, which is accessible to the central server 200 via a local storage area network (SAN), the network 450 or the network 400.
• SAN local storage area network
• the sequence dictionary 1 190 is checked.
• the current sequence of function identifiers and respective combinations of parameters (in instructions 1 through N) is compared against sequences of function identifiers and respective combinations of parameters maintained in the entries of the sequence dictionary 1 190 with the aim of determining whether the sequence dictionary 1 190 includes a sequence index corresponding to the current sequence of function identifiers and respective combinations of parameters. If the answer is affirmative, this will indicate that a packet representing this same sequence of instructions has already been created in the past, and that a sequence index has already been assigned to this particular sequence of instructions. In that case, the marshalling process proceeds to step S1 150, wherein the sequence index is retrieved from the sequence dictionary, and a packet is created such that it includes the sequence index.
• one or more instructions refers to function arguments that are not considered to be condensable, these may be appended to the packet, such as in a p re-determined location that will allow the recipient to determine which instruction the function arguments are associated with.
• step S1 160 the packet is transmitted to the remote device (e.g., the rendering server 100) over the network 450.
• the remote device e.g., the rendering server 100
• the packet also includes any necessary header or other information that would make it suitable for transmission over the network 450.
• the packet may be formatted in such a way as to alert the receiving entity that it carries a sequence index as opposed to a packet index, a function identifier or parameters.
• the marshalling process proceeds to step S1 170. This includes execution of steps 720 from the flowchart of Fig. 7A and all steps subsequent thereto, for each instruction in the sequence of instructions.
• step S1 180 the marshalling process executes step S1 180, wherein an entry is created in the sequence dictionary 1 190 for the current sequence of function identifiers and respective combinations of parameters (in instructions 1 through N), and a sequence index is assigned thereto and stored in the sequence dictionary 1 190.
• the marshalling process may effect pre-processing on the instructions that have been received thus far, which can include any of the steps in Fig. 7A with the exception of step S750. If it turns out that a sequence index will be found for the sequence currently being compiled, then this pre-processing will turn out to have been wasteful, but in the event that a sequence index is not found, such pre-processing will minimize the latency required to create the packet.
• first, third, fourth, seventh and ninth instructions are identical and refer to the same function identifier Functioncaii i and the same function arguments Paraml, Param2 and Param3.
• second, fifth and eighth instructions are identical and refer to the same function identifier Functioncaii_2 and the same function arguments Param3, Param4. It is assumed that all function arguments are condensable, and therefore qualify as "parameters" as used herein. However, this assumption is made merely for the sake of simplicity and it need not be the case in every embodiment.
• Fig. 12A shows the status of the packet dictionary 794, the function index table 790, the parameter index table 792 and the sequence dictionary 1 190 prior to receipt or processing of the first instruction.
• the packet dictionary 794, the function index table 790, the parameter index table 792 and the sequence dictionary 1 190 are all empty.
• This scenario remains substantially the same until the third instruction (i.e., the last instruction in a sequence of 3 instructions) is received. That is to say, whereas in accordance with the marshalling process of Fig. 7A, packets would be generated one at a time, this is not the case in the marshalling process of Fig. 1 1 A, because packets are not released until a complete sequence of instructions has been received. In this non-limiting case, used only for purposes of example, a complete sequence is considered to include three instructions.
• Fig. 12B shows the status of the packet dictionary 794, the function index table 790, the parameter index table 792 and the sequence dictionary 1 190 after having received and processed the third instruction.
• the parameter index table 792 includes four entries, one for each of Parami, Param2, Param3 and Param4, which are associated with parameter indexes 0x1 , 0x2, 0x3 and 0x4, respectively.
• the function index table 790 includes two entries, one for each of Functioncaii_i and Functioncaii_2, which are associated with function indexes 0x1 and 0x2, respectively.
• the packet dictionary 794 includes two entries, one for Functioncaii i together with the combination of Parami, Param2, Param3 (associated with packet index 0x1 ) and one for Functioncaii_2 together with the combination of Param3, Param4 (associated with packet index 0x2).
• the sequence dictionary 1 190 includes one entry for the first sequence of three instructions, and which is associated with sequence index 0x1 .
• Fig. 12B also shows that three packets 1210, 1220, 1230 have been issued, corresponding to the three instructions in the first sequence: Contents of PACKET 1210:
• packets 1210, 1220, 1230 may include, where appropriate, a flag to allow the recipient to distinguish between a packet index, a function identifier, a function index, a parameter and a parameter index.
• Fig. 12C shows the status of the packet dictionary 794, the function index table 790, the parameter index table 792 and the sequence dictionary 1 190 after having received and processed the sixth instruction.
• the parameter index table 792 includes two new entries, one for each of Param5 and Param6, which are associated with parameter indexes 0x5 and 0x6, respectively.
• the function index table 790 includes one new entry for Functioncaii_3, which is associated with function index 0x3.
• the packet dictionary 794 includes one new entry for Functioncaii_3 together with the combination of Param5, Param6, which is associated with packet index 0x3.
• the sequence dictionary 1 190 includes a new second entry for the second sequence of three instructions, and which is associated with sequence index 0x2.
• Fig. 12C also shows that three packets 1240, 1250, 1260 have been issued, corresponding to the three instructions in the second sequence:
• packet index 0x1
• packet 1270 is a very short packet that includes sequence index 0x1 .
• packet 1270 may include a flag or header to indicate that it is conveying a sequence index rather than, say, a packet index.
• the detection of sequences can be done based on the packets output by the marshalling process of Fig. 7A, rather than directly on the basis of received instructions. That is to say, once packets have been created and are ready to be transmitted in accordance with the marshalling process of Fig. 7A, it is possible to analyze these packets in order to identify sequences of packets (rather than instructions) and issue condensed packets that include sequence numbers where possible.
• a complementary unmarshalling process can be carried out at the remote device (e.g., the rendering server 100), so as to decode the sequence identifier where one is present in the incoming packet and, in the alternative, to assign a sequence identifier to an incoming sequence of packets.
• the remote device e.g., the rendering server 100
• Figs. 14A and 14B three local stubs 1410, 1415, 1420 are instantiated on the same local device 1430.
• the local device 1430 executes the game state management process.
• the local stubs 1410, 1415, 1420 make remote procedure calls to corresponding remote stubs 1450, 1455, 1460 disposed on a common remote device 1470.
• the local device 1430 can be the central server 200 and the remote device 1470 can be the rendering server 100.
• the local device 1430 and the remote device 1470 may be connected by the network 450.
• the function calls made by local stub 1410 are marshaled into packets, which are then sent to and serviced by remote stub 1450. This can result in the rendering of game screens for a first participant in the game.
• function calls made by local stub 1415 are marshaled into packets, which are then sent to and serviced by remote stub 1455
• function calls made by local stub 1420 are marshaled into packets, which are then sent to and serviced by remote stub 1460. This results in the rendering of game screens for a second and a third participant in the game, respectively.
• Memory space 1440 includes a function index table 1442, a parameter index table 1444 and a packet dictionary 1446 for use by local stub 1410.
• Memory space 1440 may also include a sequence dictionary 1448 when useful or desired.
• the function index table 1442, the parameter index table 1444, the packet dictionary 1446 and the sequence dictionary 1448 are accessed by local stub 1410 when executing a marshalling process for participant #1 .
• memory spaces 1445 and 1449 are similarly configured, with a respective function index table, a respective parameter index table, a respective packet dictionary and possibly also a respective sequence dictionary.
• These separate memory spaces 1445, 1450 are separately accessed by local stubs 1415, 1420 when executing distinct marshalling processes for participants #2 and #3, respectively.
• Memory space 1480 includes a function index table 1482, a parameter index table 1484 and a packet dictionary 1486 for use by remote stub 1450.
• Memory space 1480 may also include a sequence dictionary 1488 when useful or desired.
• the function index table 1482, the parameter index table 1484, the packet dictionary 1486 and the sequence dictionary 1488 are accessed by remote stub 1450 when executing an unmarshalling process for participant #1 .
• memory spaces 1485 and 1490 are similarly configured, with a respective function index table, a respective parameter index table, a respective packet dictionary and possibly also a respective sequence dictionary.
• the three local stubs 1410, 1415 1420 have access to a shared memory space 1461 .
• the shared memory space 1461 includes a common function index table 1462, a common parameter index table 1464 and a common packet dictionary 1466.
• the shared memory space 1461 may also include a common sequence dictionary 1468 when useful or desired. Therefore, the function index table 1462, the parameter index table 1464, the packet dictionary 1466 and the sequence dictionary 1468 are commonly accessed by local stubs 1410, 1415, 1420 executing distinct marshalling processes for participants #1 , #2 and #3, respectively.
• the shared memory space 1461 may be configured in various ways.
• the shared memory space 1461 can be maintained in the central RAM 203 or the central storage medium 204.
• the shared memory space 1461 can be maintained in the central RAM 203 or the central storage medium 204.
• the shared memory space 1461 can be maintained in the central RAM 203 or the central storage medium 204.
• SAN local storage area network
• the shared memory space 1475 includes a common function index table 1492, a common parameter index table 1494 and a common packet dictionary 1496.
• the shared memory space 1475 may also include a common sequence dictionary 1498 when useful or desired. Therefore, the function index table 1492, the parameter index table 1494, the packet dictionary 1496 and the sequence dictionary 1498 are commonly accessed by remote stubs 1450, 1455, 1460 executing distinct unmarshalling processes for participants #1 , #2 and #3, respectively.
• the shared memory space 1475 may be configured in various ways.
• the shared memory space 1475 can be maintained in the RAM 103 or the storage medium 104.
• the shared memory space 1475 can be maintained on external storage, which is accessible to the rendering server 100 via a local storage area network (SAN), the network 450 or the network 400.
• SAN local storage area network
• Fig. 15 illustrates a non-limiting embodiment in which three local stubs 1510, 1515, 1520 are instantiated on three separate local devices 1530, 1535, 1540.
• the local stubs 510, 1515, 1520 make remote procedure calls to corresponding remote stubs 1550, 1555, 1560.
• remote stubs 1550, 1555, 1560 are instantiated on a single remote device 1570.
• the remote stubs 1550, 1555, 1560 may be instantiated on separate remote devices. It is to be understood that although the number of local and remote stubs is three, this is not to be considered a limitation of the present invention.
• the local devices 1530, 1545, 1540 can be sub- portions of a distributed central server 200, while the remote device 1570 can be the rendering server 100.
• the game state management process may be run by one of the local devices 1530, 1535, 1540 that is designated as the "master", or the game state management process may be collaboratively / distributedly executed by the local devices 1530, 1535, 1540.
• the local devices 1530, 1545, 1540 can be game consoles, while the remote device 570 can be the rendering server 00 or the central server 200.
• the game state management process may be run by one of the game consoles that is designated as the "master", or the game state management process may be collaboratively / distributedly executed by the various game consoles.
• Local stub 1510 responds to the receipt of instructions by executing a marshalling process to create packets, which are sent to and serviced by remote stub 1550. This can result in the rendering of game screens for a first participant in the game. Likewise, local stubs 1515, 1520 execute their own marshalling processes that result in the transmission of packets to remote stubs 1555, 1560, respectively. This results in the rendering of game screens for a second and a third participant in the game, respectively.
• the three local stubs 1510, 1515, 1520 have access to a shared memory space 1580.
• the shared memory space 1580 includes a common function index table 1582, a common parameter index table 1584 and a common packet dictionary 1586.
• the shared memory space 1580 may also include a common sequence dictionary 1588 when useful or desired. Therefore, the function index table 1582, the parameter index table 1584, the packet dictionary 1586 and the sequence dictionary 1588 are commonly accessed by local stubs 1510, 1515, 1520 executing distinct marshalling processes for participants #1 , #2 and #3, respectively.
• the shared memory space 1580 may be configured in various ways. For example, one possibility is for the shared memory space 1580 to be maintained in the memory (e.g., RAM or other storage medium) of one of the local devices 1530, 1535, 1540 and continuously accessed by the local stubs 1510, 1515, 1520, including those that are outside of the local device where the shared memory space is located.
• the shared memory space 1580 may be maintained in the memory (e.g., RAM or other storage medium) of one of the local devices 1530, 1535, 1540 and continuously accessed by the local stubs 1510, 1515, 1520, including those that are outside of the local device where the shared memory space is located.
• the shared memory space 1580 is maintained on external storage, which is accessible to the local devices 1530, 1535, 1540 via a storage area network (SAN) and/or the network 450 or the network 400.
• SAN storage area network
• the shared memory space 1580 is replicated within each of the local devices 1530, 1535, 1540 (e.g., within a cache) so as to provide faster access to the function index table 1582, the parameter index table 1584, the common packet dictionary 1586 (and the sequence dictionary 1588, when used).
• the local devices 1530, 1535, 1540 can carry out a protocol for building copies of the shared memory space 1580 in each of the local devices 530, 1535, 1540.
• remote stubs 1550, 1555, 1560 are executed by a single remote device 1570, the may be configured as previously described with reference to Fig. 14B.
• a remote procedure call in a gaming environment includes an instruction to initialize a process.
• Still other examples of a remote procedure call in a gaming environment include fetching the leader-board, finding other players or retrieving game news.
• the present invention is not limited to a gaming environment.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• Multimedia (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Optics & Photonics (AREA)
• Quality & Reliability (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Information Transfer Between Computers (AREA)
• Health & Medical Sciences (AREA)
• Computing Systems (AREA)
• General Health & Medical Sciences (AREA)
• Medical Informatics (AREA)

Priority Applications (3)

Applications Claiming Priority (6)

Publications (1)

Family

ID=49877111

Family Applications (1)

Country Status (5)

Families Citing this family (8)

Family Cites Families (9)

• 2012
  • 2012-10-22 CA CA2793154A patent/CA2793154C/en active Active
• 2013
  • 2013-04-15 JP JP2015519372A patent/JP6114388B2/ja active Active
  • 2013-04-15 EP EP13750595.4A patent/EP2867773A2/en not_active Withdrawn
  • 2013-04-15 WO PCT/IB2013/001045 patent/WO2014001862A2/en not_active Ceased
  • 2013-04-15 US US14/410,842 patent/US10051084B2/en active Active

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events