US 20070060373 A1
A data communication system and methods are disclosed. One of the methods includes receiving portions of information such as game content information. The portions are compared to a maximum transmission unit of a network, and combined if their combination is smaller than the maximum transmission unit. Combining of the information portions allows for efficient communication of the information portions. The information portions may also be divided into segments and combined with other portions for communication.
1. A method, comprising:
receiving at a communication device a first portion of game information from a first game server external to the communication device;
receiving a second portion of game information at the communication device;
determining if a combination of the first portion of game information and the second portion of game information exceeds a maximum transmission unit associated with a network;
in response to determining that the combination of the first portion of game information and the second portion of game information do not exceed the maximum transmission unit, combining the first portion and the second portion of game information to form a first transmission packet; and
sending the first transmission packet to a first game client via the network.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
in response to determining that the combination of the first portion of game information and the second portion of game information exceeds the maximum transmission unit:
combining a first segment of the second portion of game information with the first portion of game information to form a second transmission packet;
sending the second transmission packet to the game client via the network;
forming an Nth transmission packet including a second segment of the second portion of game information; and
sending the Nth transmission packet to the game client via the network.
8. The method of
9. The method of
10. The method of
creating a header for the first transmission packet, wherein the header indicates a size of the first portion of game information and a size of the second portion of game information.
11. The method of
12. The method of
storing the second portion of game information at the communication device;
receiving an Nth portion of game information at the communication device;
combining the Nth portion of game information and the stored second portion of game information to form a second transmission packet; and
providing the second transmission packet to a second game client via the network.
13. A method comprising:
receiving a first transmission packet at a game client;
determining that the first transmission packet includes a first portion of game information and a first segment of a second portion of game information;
storing the first segment of the second portion of game information;
receiving a second transmission packet at the game client;
determining that the second transmission packet includes an Nth portion of game information and a second segment of the second portion of game information; and
combining the first segment and the second segment of the second portion of game information.
14. The method of
determining that the first transmission packet includes a first segment of an Nth portion of game information;
storing the first segment of the Nth portion of game information;
receiving a second transmission packet at the game client;
determining that the second transmission packet includes a second segment of the Nth portion of game information; and
combining the first segment and the second segment of the Nth portion of game information.
15. The method of
determining a length of the first segment of the second portion of game information based on a header of the first transmission packet.
16. The method of
storing the first portion of game information in a first receive packet;
wherein combining the first segment and the second segment of the second portion of game information comprises storing the first segment and the second segment in a second receive packet;
providing the first receive packet and the second receive packet to a receive packet stack of the game client.
17. A system, comprising:
a housing component at least partially defining an enclosure;
a first processor located within the enclosure, the first processor operable to execute at least a portion of a locally stored game server and to communicate with a remote game client; and
a packet mixing module, the packet mixing module responsive to the first processor and operable to intercept packets of game information between the first processor and the remote game client, to combine the packets of game information to form packets of combined game information, and to transmit the packets of combined game information to the remote game client.
18. The system of
19. The system of
20. The system of
21. The system of
This application claims priority to U.S. Provisional Patent Application No. 60/596,258, entitled “METHOD AND SYSTEM OF DATA TRANSMISSION AND RECEPTION USING EFFICIENT BANDWIDTH,” filed on Sep. 12, 2005, which is assigned to the current assignee hereof and are incorporated herein by reference in its entirety.
The present disclosure relates generally to network communications, and more specifically to a system and method for managing communicative interactions between network elements.
A network may be characterized by several factors like who can use the network, the type of traffic the network carries, the medium carrying the traffic, the typical nature of the network's connections, and the transmission technology the network uses. For example, one network may be public and carry circuit switched voice traffic while another may be private and carry packet switched data traffic. Whatever the make-up, most networks facilitate the communication of information between at least two nodes, and as such act as communication networks.
In recent years, several applications have been developed that rely on timely and effective interactions between two or more elements of a communication network. For example, in the sphere of online gaming, hundreds or thousands of game clients executing on user machines may be interacting with a central server executing on a networked computer. With such an architecture, the networked server computer is frequently tasked with providing content to clients, receiving client requests, processing those requests, responding to those requests, and synchronizing those requests with the requests of other clients. Further, the networked server computer can also be tasked with communicating different types of information to the client computer. Certain information, such as information representing player movement, event feedback or other information is communicated frequently in small portions of information. Other information, such as game patches, game world updates, and the like may be communicated less frequently, but includes larger portions of information. The perceived and/or real ability of the game server to communicate the small portions of information may be adversely affected when the larger portions of information are being communicated.
In the gaming context, if communicative interactions are adversely affected or overly numerous, a game player may experience distracting events such as game freezes, stuttering, warping, etc. As such, a need exists for a data communication system and method that manages communicative interactions between network elements.
It will be appreciated that for simplicity and clarity of illustration, elements illustrated in the Figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to other elements. Embodiments incorporating teachings of the present disclosure are shown and described with respect to the drawings presented herein, in which:
Embodiments discussed below describe, in part, distributed computing solutions that manage all or part of a communicative interaction between network elements. In this context, a communicative interaction may be one or more of: intending to send information, sending information, requesting information, receiving information, or receiving a request for information. As such, a communicative interaction could be one directional, bi-directional, or multi-directional. In some circumstances, a communicative interaction could be relatively complex and involve two or more network elements. For example, a communicative interaction may be “a conversation” or series of related communications between a client and a server—each network element sending and receiving information to and from the other. Whatever form the communicative interaction takes, it should be noted that the network elements involved need not take any specific form. A network element may be a node, a piece of hardware, software, firmware, middleware, some other component of a computing system, and/or some combination thereof.
Though much of the following discussion focuses on specific problems associated with online gaming, the teachings disclosed herein may have broader applicability. As such, discussions relating to gaming issues like lag, game freezes, stuttering, warping, etc. are not intended to limit the scope of the disclosure. In addition, though the specific embodiment described in connection with
From a high level, a system incorporating teachings of the present disclosure may include a processor module that monitors communications between a client program resident on a user machine and a server program resident on a computing device remote from the user. The server program may be part of a two-tier architecture that is deployed in a hub and spoke or centralized server configuration. The server program may also be utilized in a less centralized model. For example, the server program may be implemented as one of two or more client programs that perform server-like functionality.
However, the server program is implemented, the processor module may be utilized to effectively reduce the number of communications actually transmitted between the client program and the server program. For example, the processor module may intercept certain client initiated communications intended for the server program, process those communications without server program involvement, and respond to the client program. In some circumstances, the processor module may make it unnecessary to actually send the original client request to the server. Depending upon implementation detail, a different message—one indicating that the original client request has already been handled—may be sent from the processor module to the server. In practice, processing the communications without burdening the server program and without traversing a portion of the network may help reduce problems such as latency, lag, and loss of data coherency. Though the above discussion involves a client-to-server communication, the processor module may also be configured to affect server-to-client communications as well.
As indicated above, this application claims priority to U.S. Provisional Patent No. 60/596,258, filed on Sep. 12, 2005. The provisional applications describe in part specific implementations of the teachings disclosed herein and are not intended to limit the scope of the claims attached below. The entirety of the provisional application is incorporated herein by reference.
The actual location of mixing function 106 may be modified in other deployments. For example, the mixing function 106 may be located at the host transmitter device 102. Further, the mixing function 106 may be implemented as a processor dongle, a “Lan on Motherboard” processor, etc. The unmixing function 112 may also be implemented at the receiving node 110 or in a different location, and may also be implemented as processor dongle, a “Lan on Motherboard” processor, and the like.
Within arrangement 100, the host transmitter device 102 and the receiving node 110 may be similar or different. For example, receiving node 110 may be a local user computer, a laptop, a cellular telephone, a gaming console, a workstation, or some other appropriate device, and host transmitter device 102 may be a server computer, a workstation, a peer of receiving node 110, or some other appropriate device.
In the embodiment of
During operation, the host transmitter device 102 communicates with the receiving node 110 by sending information via the network 108. The information can be divided into portions, and each information portion may be of different sizes. Further, the information portions provided can be smaller than the MTU for the network 108. The information portions are received at the offload transmitter device 104, which analyzes the information portions. If an information portion is smaller than the MTU, or other threshold, the offload transmitter device can apply the mixing function 106 to mix portions of received information together. For example, the host transmitter device 102 may provide different portions of information from different applications operating at the host transmitter device 102. The offload transmitter device 104 can determine that one or more of the provided portions are smaller than the MTU, and can combine the provided portions into an information unit, such as a transmission packet. The transmission packet is communicated to the receiving node 110 via the network 108.
The receiving node 110 receives the transmission packet and analyzes it to determine if the packet includes one or more portions of information. If so, the receiving node 110 applies the unmixing function 112 to the transmission packet to separate each portion of information provided by the transmission packet.
By combining information portions into transmission packets, information may be sent efficiently via the network 108. Further, by placing the mixing function 106 in the offload transmitter device 104, the processing load and overhead for the host transmitter device can be reduced.
In operation, the game server 202 and the game client 210 may communicate with each other via the network 208. In one embodiment game server 202 and the game client 210 may work together to provide a user of game client 210 with an online gaming experience. Game client 210 may receive content generated by the game application 220 from game server 202 and may occasionally send requests game server 202 in an effort to affect the content being provided. As shown,
For example, in some embodiments, game server 202 may be hosting and serving a massively multiplayer online game (MMOG) environment to hundreds or thousands of users. The content that makes up the environment may include, for example, game objects, game players, images, sounds, text, etc. This content may eventually be received and presented to the user of game client 210 via a computer screen, audio speakers, or other appropriate device.
In the particular embodiment of
In some situations, game application 220 may “allow” the request and provide new or altered content based on the allowance. For example, if the game interaction request is to move a game player, the game application 220 can produce the player moves 221 information portion 224 that shows that a player has been moved. In a MMOG environment, the game application 220 may also be tasked with providing the new or altered content to multiple users at multiple locations via network 104. Information portions such as player moves 224 can be relatively small portions of information that are communicated frequently during game activity, in order to provide the user at the game client 210 with the desired game experience.
The game application 220 may also generate relatively large portions of information, such as a game patch information portion 226. The game patch 226 can be generated to adjust the client program at the game client 210, including implementing updated or new game features and content, security features, stability controls, and the like. Other large portions of information can be generated. For example, the game application 220 can generate a pre-cache of game data for the game client 210. This pre-cache can represent game states or other information used to generate subsequent game states at the game client 210. Such pre-caching can reduce lag or other game experience issues at the game client 210.
The large portions of information, such as the game patch 226, can be communicated to the game client 210 via the network 208. However, communication of such large information portions during game activity can interfere with communication of smaller portions of information such as player moves 224. This can result in distracting events (sometimes called lag) such as game freezes, stuttering, warping, and rubber banding. Although transmission of large information portions can be postponed until times of lesser game activity, such as on game startup, this can undesirably delay the implementation or use of the information in the large information portions. For example, a large information portion can include a large update to the gaming environment for multiple clients. It may be desirable to implement this update during periods of active game activity.
The mixing function 206 at the offload transmitter device can mix large information portions with small information portions and transmit the combined portions in a transmission packet to the game client 210. The combined portions are unmixed at the game client 210 for processing. By combining the information portions, the offload transmitter device 204 can maintain the appropriate game experience and provide large portions of information to the game client 210. For example, the offload transmitter device 204 can combine the player moves information portion 224 with the game patch information 226 and provide the combined information to the game client 210. After the information portions are unmixed, the game client 210 can implement the player moves 224 so that the user enjoys the desirable game experience, and also implement the game patch 226 so that the game client 210 includes the latest version of the game client program.
The mixing function 206 can also break down large portions of information into segments, and combine each segment with smaller portions of information for transmission. This can be useful when the large portions of information exceed the MTU of the network 208 or other bandwidth parameter. For example, the mixing function 206 can determine that the game patch 226 exceeds the MTU for the network 208, and therefore divide the game patch into segments. One or more of the segments can be mixed with the player moves 224 into a transmission packet. The transmission packet is received at the game client 210, and the unmixing function 212 unmixes the player moves 224 with the attached segments. The player moves 224 are implemented by the game client 210, while the data segments are stored. The remaining data segments are sent by the offload transmitter device 204, and the unmixing function 212 reconstructs the game patch 226 from the received and stored data segments. Accordingly, the offload transmitter device 204 is able to transmit large portions of information during periods of active game play activity.
If the combination will not exceed the MTU, the method flow moves to block 306 and the received packet is added to the transmission packet. The method flow then proceeds to decision block 308, and the communication module determines if the transmission packet is now sized at the MTU. If so, the method flow moves to block 312 and the transmission packet is provided to a transmission stack for transmission. The transmission stack can be a standard transmission stack, so that no additional processing is required to communicate a transmission packet that includes multiple received packets. If, at block 308, it is determined that the transmission packet can accommodate additional data, the method flow returns to decision block 302 to await additional packets.
Returning to decision block 304, if it is determined that the combination of the current transmission packet and the received packet will exceed the network MTU, the method flow moves to block 314 and the communication module subdivides the received packets into segments. Proceeding to block 316, one or more of the segments are added to the transmission packet. In a particular embodiment, segments are added until adding another packet would cause the transmission packet to exceed the MTU. The method flow moves to block 318 and the segments that have not been added to the transmission packet are stored. The stored segments can be added to subsequent transmission packets for transmission. The method flow then moves to block 308.
Returning to decision block 302, if a packet is not received, the method flow moves to decision block 310 and the communication module determines if a time out threshold has been reached. If not, the method flow returns to block 302. If the time out threshold has been reached or exceeded, the method flow moves to block 312 and the current transmission packet is provided to the transmission stack. The time out process allows for partially “full” transmission packets to be sent after a certain period of time. This can be useful in applications such as the game application described above, where it is desirable to communicate game interactions and event updates in a timely manner to provide the desired game experience.
Moving to block 406, the receiving node copies any complete information portions in the transmission packet into receive packets. The receive packets can be configured for a receive stack at the receiving node. The receive stack can be a standard receive stack that includes both packets representing data unmixed at the receiving node and packets received directly from a network.
Proceeding to decision block 408, the receiving node determines if there are any data segments in the received transmission packet. If not, the method flow moves to block 416 and the prepared receive packets are provided to the receive stack. If data segments are identified in the transmission packet, the method flow proceeds to block 410 and the identified data segments are added to any stored data segments associated with the same information portion. The method flow then moves to decision block 412 and the receiving node determines if the stored data segments constitute a complete data portion. If not, the method flow moves to block 416 and the prepared receive packets are provided to the receive stack. If a complete information portion is stored, the method flow moves to block 414 and the complete data portion is copied to a receive packet. The method flow then proceeds to block 416.
The processor 503 can be a microprocessor, a microcomputer, a central processing unit (CPU) or other processing device. The network interface 506 can be an Ethernet card or chip or other network interface device. The memory 508 can be a random access memory (RAM), a hard drive, or other appropriate memory device.
During operation, the processor 503 runs the server program 510. The server program 510 can be a game program, a multimedia player such as a video or audio player, or other program. The server program 510 interacts with a client program over a wide area network, as explained with respect to
For example, the server program 510 can be a game program. During execution of the server program 510, the processor 503 can send game content to a game program resident on a remote client. The game content can consist of information portions, such as player move portions, game patch portions, game update portions, and the like. The mixing module 504 can monitor the portions and determine if the portions can be combined and still remain within the MTU parameters of the network. The mixing module can also break down large information portions into segments and combine the segments with other information portions for transmission.
In addition, the mixing module 504 may be implemented externally to the housing 502. For example, the mixing module 504 can be implemented as a separated device having its own processor and memory. Further, the mixing module 504 can store a persistent copy of the large portions of information received from the processor 503. These stored copies can be used to provide information to clients without further involvement of the processor 503. For example, the mixing module 504 can store a copy of game patch information provided by the processor 503. When a particular client accesses the server 500, such as by initiating a game session, the mixing module 504 can combine the game patch information with other game information and provide the combined information to the client. This relieves the processor 503 from having to monitor which clients have received the patch information, as each client will be provided the patch information when a game session is initiated.
Although only a few exemplary embodiments have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of the embodiments of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of the embodiments of the present disclosure as defined in the following claims. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents, but also equivalent structures.