U.S. patent application number 11/519682 was filed with the patent office on 2007-03-15 for data communication system and methods.
This patent application is currently assigned to Bigfoot Networks, Inc.. Invention is credited to Harlan Titus Beverly.
Application Number | 20070060373 11/519682 |
Document ID | / |
Family ID | 37855997 |
Filed Date | 2007-03-15 |
United States Patent
Application |
20070060373 |
Kind Code |
A1 |
Beverly; Harlan Titus |
March 15, 2007 |
Data communication system and methods
Abstract
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.
Inventors: |
Beverly; Harlan Titus;
(McDade, TX) |
Correspondence
Address: |
LARSON NEWMAN ABEL POLANSKY & WHITE, LLP
5914 WEST COURTYARD DRIVE
SUITE 200
AUSTIN
TX
78730
US
|
Assignee: |
Bigfoot Networks, Inc.
Austin
TX
|
Family ID: |
37855997 |
Appl. No.: |
11/519682 |
Filed: |
September 12, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60596258 |
Sep 12, 2005 |
|
|
|
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
A63F 13/358 20140902;
A63F 2300/552 20130101; A63F 2300/534 20130101; A63F 13/12
20130101; A63F 13/77 20140902 |
Class at
Publication: |
463/042 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
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 claim 1, wherein the communication device is a
software device.
3. The method of claim 1, wherein the first portion of game
information represents player movement information.
4. The method of claim 1, wherein the second portion of game
information represents game patch information.
5. The method of claim 1, wherein the second portion of game
information represents an update of game information for a
plurality of game clients.
6. The method of claim 1, wherein the second portion of game
information represents a pre-caching of game content.
7. The method of claim 1, further comprising: 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 claim 7, wherein the Nth transmission packet
includes an Nth portion of game information.
9. The method of claim 1, wherein the second portion of game
information is received from a second game server.
10. The method of claim 1, further comprising: 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 claim 1 wherein the first portion of game
information is received from a first game application at the game
server and the second portion of game information is received from
a second game application at the game server.
12. The method of claim 1, further comprising: 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 claim 13, further comprising: 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 claim 13, further comprising: 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 claim 13, further comprising: 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 claim 17, wherein the packet mixing module is
external to the enclosure.
19. The system of claim 17 wherein the packet mixing module is a
software or firmware module of the first processor.
20. The system of claim 17, wherein the packet mixing module is
further operable to subdivide one or more packets of game
information to form subdivided packets of game information, and
wherein the one or more of the packets of combined game information
includes one or more subdivided packets of game information.
21. The system of claim 17, wherein at least one of the packets of
combined game information includes game patch information and game
status information.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] 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.
FIELD OF THE DISCLOSURE
[0002] The present disclosure relates generally to network
communications, and more specifically to a system and method for
managing communicative interactions between network elements.
BACKGROUND
[0003] 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.
[0004] 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.
[0005] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] 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:
[0007] FIG. 1 is a block diagram of a particular embodiment of a
network arrangement incorporating teachings of the present
disclosure;
[0008] FIG. 2 is a block diagram of an alternative particular
embodiment of a network arrangement incorporating teachings of the
present disclosure;
[0009] FIG. 3 is a flow diagram of a particular embodiment of a
technique for mixing data packets;
[0010] FIG. 4 a flow diagram of a particular embodiment of a
technique for mixing data packets; and
[0011] FIG. 5 is a block diagram of a particular embodiment of a
computing device that incorporates teachings of the present
disclosure.
[0012] 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.
[0013] 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 FIG. 1 involves a Massively Multiplayer Online
Game (MMOG), other interactive applications such as Video On
Demand, entertainment distribution, information distribution, etc.,
may also be implemented in a manner that incorporates the teachings
disclosed herein.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] Referring to FIG. 1, a block diagram of a particular
embodiment of a network arrangement 100 is illustrated. The network
arrangement 100 includes a host transmitter device 102 connected to
an offload transmitter device 104. The offload transmitter device
104 is connected to a network 108, which is further connected to a
receiving node 110. The offload transmitter device 104 includes a
mixing function 106, while the receiving node 110 includes an
unmixing function 112.
[0018] 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.
[0019] 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.
[0020] In the embodiment of FIG. 1, network 108 may be a wide area
network, such as the Internet, a local area network, or some other
appropriate network or bus. Units of information, such as
information packets and the like, are communicated via the network
108. The network 108 is characterized by a maximum transmission
unit (MTU) which describes the largest amount of information that
can be communicated in one unit by the network 108. The MTU can be
expressed as a packet size or other appropriate unit.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] Referring to FIG. 2, a particular embodiment of a network
arrangement 200, corresponding to the network arrangement 100 of
FIG. 1, is illustrated. The network arrangement 200 includes a game
server 202 connected to an offload transmitter device 204. The
offload transmitter device 204 is connected to a network 208, which
is further connected to a game client 210. The offload transmitter
device 204 includes a mixing function 206, while the game client
210 includes an unmixing function 212. The game server includes a
game application 220 and a game networking module 222. The game
application 220 generates portions of information, such as player
moves 224 and game patch 226.
[0025] 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, FIG. 2 includes only one device executing a
client program. In practice, however, the game server 202 and game
application 220 may be providing content to many clients at or near
the same time.
[0026] 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.
[0027] In the particular embodiment of FIG. 2, game client 210 may
implement a local game program or client application that performs
several tasks including the receipt of content provided by the game
server 202. The game client 210 may process certain content and
facilitate a user's interaction with the game application 220. For
example, a user may input a game interaction request via some user
input device associated with game client 210. The input may "tell"
the game client 210 to select game objects, move game objects,
interact with other game players, and the like. The game
application 210 may receive the game input request.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] Referring to FIG. 3, a flow diagram of a particular
embodiment of a method of communicating data is illustrated. At
decision block 302 a communication module determines if a packet
has been received. If a packet has been received, the method flow
moves to block 304, and the communication module determines if the
received packet can be added to the current transmission packet
without exceeding the MTU for an associated network. Other
parameters may also be considered, such as the size of any headers
or other information that is appended to the transmission
packet.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] Referring to FIG. 4, a flow diagram of a particular
embodiment of a method of unmixing received information portions is
illustrated. At block 402, a transmission packet is received at a
receiving node. Moving to block 404, the receiving node reads a
header of the transmission packet. The header indicates what
information is contained in the transmission packet. For example,
the header can indicate that the transmission packet includes
multiple portions of information, such as player move information
and game patch information. The header can also indicate that the
transmission packet includes segments of a particular information
portion.
[0038] 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.
[0039] 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.
[0040] Referring to FIG. 5, a particular embodiment of a server
500, such as the game server 202 of FIG. 2, is illustrated. The
server 500 includes a housing 502 that defines a physical
enclosure. Disposed within the housing 502 are a processor 503, a
mixing module 504, a network interface 506, and a memory 508. The
memory stores a server program 510. The memory 508 is accessible to
the processor 503. The mixing module 504 is connected to the
processor 503 and to the network interface 506. In some
embodiments, the network interface 506 might be built into the
mixing module 504, and mixing module 504 may look as though it is a
Network Card to the Processor and run via a PCI Bus. In other
embodiments, the mixing module 504 may be software or firmware
running on the main or other processor.
[0041] 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.
[0042] 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 FIG. 1.
[0043] 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.
[0044] 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.
[0045] 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.
* * * * *