Patent Grant
7240162
Software streaming involves downloading small pieces of files as the pieces are needed by the program being streamed. These small pieces may be referred to as blocks. A streaming client sends requests for blocks as they are needed up to a streaming server, which sends back streaming data that is associated with the requested block. Sending a request and receiving the streaming data may cause delays that can slow down the streamed program.
There are many problems associated with streaming software that it would be advantageous to negate, work around, or reduce. For example, predicting blocks for streaming has not been satisfactorily addressed.
A technique for predictive streaming involves receiving a request for a first block of a streaming application, checking a block request database, predicting a second block request based on the block request database, and sending, in response to the request, data associated with the first block and data associated with the second block. A block may be an arbitrarily large portion of a streaming application. The block request database includes probabilities or means for determining probabilities that the second block will be requested given that the first block has been requested. One or more factors may be considered when determining the probability of a request for the second block. Data sent in response to the request may include data associated with the first block and data associated with the second block. The data associated with the first block and the data associated with the second block may not be analogous. In an embodiment, the data associated with the first block is responsive to a block request for the first block, while the data associated with the second block is data sufficient to facilitate making a request for the second block.
In an embodiment, the technique may further include predicting block requests based on the block request database, then sending data associated with the block requests. In another embodiment, the data associated with the second block includes data sufficient to render a request for the second block unnecessary. In another embodiment, the technique further includes piggybacking the data associated with the second block on a reply to the request for the first block. In another embodiment, the technique further includes logging the request for the first block and updating the block request database to incorporate data associated with the logged request. In another embodiment, the technique further includes setting an aggressiveness parameter, wherein the data associated with the second block is sent when a probability of the second block request is higher than the aggressiveness parameter.
A system constructed according to the technique may include a processor, a block request database that includes predictive parameters, a prediction engine that is configured to check the block request database and predict a second block request for a second block based upon a first block request for a first block and predictive parameters associated with the first block, and a streaming server. The streaming server may be configured to obtain the prediction about the second block request from the prediction engine, include data associated with the second block in a response to the first block request, in addition to data associated with the first block, and send the response in reply to the first block request.
In an embodiment, the data associated with the second block is sufficient to identify the second block so as to facilitate making the second block request. In another embodiment, the data associated with the second block includes data sufficient to render the second block request unnecessary. In another embodiment, the streaming server is further configured to piggyback the data associated with the second block on a reply to the first block request. In another embodiment, the system includes a request log, wherein the streaming server is further configured to log the first block request in the request log. The prediction engine may be further configured to update the block request database according to the request log.
Parametric predictive streaming involves maintaining parameters (parametric) to predict (predictive) which blocks will be requested by or served to a streaming client (streaming). Parametric predictive streaming can improve pipe saturation with large reads or facilitate rapid provision of sequential small reads. Parametric predictive streaming may, in an exemplary embodiment, also be adaptive. Parametric predictive adaptive streaming involves changing parameters over time as access patterns are learned.
The following description of
The web server 104 is typically at least one computer system which operates as a server computer system and is configured to operate with the protocols of the world wide web and is coupled to the Internet. The web server system 104 can be a conventional server computer system. Optionally, the web server 104 can be part of an ISP which provides access to the Internet for client systems. The web server 104 is shown coupled to the server computer system 106 which itself is coupled to web content 108, which can be considered a form of a media database. While two computer systems 104 and 106 are shown in
Access to the network 102 is typically provided by Internet service providers (ISPs), such as the ISPs 110 and 116. Users on client systems, such as client computer systems 112, 118, 122, and 126 obtain access to the Internet through the ISPs 110 and 116. Access to the Internet allows users of the client computer systems to exchange information, receive and send e-mails, and view documents, such as documents which have been prepared in the HTML format. These documents are often provided by web servers, such as web server 104, which are referred to as being “on” the Internet. Often these web servers are provided by the ISPs, such as ISP 110, although a computer system can be set up and connected to the Internet without that system also being an ISP.
Client computer systems 112, 118, 122, and 126 can each, with the appropriate web browsing software, view HTML pages provided by the web server 104. The ISP 110 provides Internet connectivity to the client computer system 112 through the modem interface 114, which can be considered part of the client computer system 112. The client computer system can be a personal computer system, a network computer, a web TV system, or other computer system. While
Similar to the ISP 114, the ISP 116 provides Internet connectivity for client systems 118, 122, and 126, although as shown in
Client computer systems 122 and 126 are coupled to the LAN 130 through network interfaces 124 and 128, which can be ethernet network or other network interfaces. The LAN 130 is also coupled to a gateway computer system 132 which can provide firewall and other Internet-related services for the local area network. This gateway computer system 132 is coupled to the ISP 116 to provide Internet connectivity to the client computer systems 122 and 126. The gateway computer system 132 can be a conventional server computer system.
Alternatively, a server computer system 134 can be directly coupled to the LAN 130 through a network interface 136 to provide files 138 and other services to the clients 122 and 126, without the need to connect to the Internet through the gateway system 132.
The computer 142 interfaces to external systems through the communications interface 150, which may include a modem or network interface. It will be appreciated that the communications interface 150 can be considered to be part of the computer system 140 or a part of the computer 142. The communications interface can be an analog modem, isdn modem, cable modem, token ring interface, satellite transmission interface (e.g. “direct PC”), or other interfaces for coupling a computer system to other computer systems.
The processor 148 may be, for example, a conventional microprocessor such as an Intel Pentium microprocessor or Motorola power PC microprocessor. The memory 152 is coupled to the processor 148 by a bus 160. The memory 152 can be dynamic random access memory (dram) and can also include static ram (sram). The bus 160 couples the processor 148 to the memory 152, also to the non-volatile storage 156, to the display controller 154, and to the I/O controller 158.
The I/O devices 144 can include a keyboard, disk drives, printers, a scanner, and other input and output devices, including a mouse or other pointing device. The display controller 154 may control in the conventional manner a display on the display device 146, which can be, for example, a cathode ray tube (CRT) or liquid crystal display (LCD). The display controller 154 and the I/O controller 158 can be implemented with conventional well known technology.
The non-volatile storage 156 is often a magnetic hard disk, an optical disk, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory 152 during execution of software in the computer 142. One of skill in the art will immediately recognize that the terms “machine-readable medium” or “computer-readable medium” includes any type of storage device that is accessible by the processor 148 and also encompasses a carrier wave that encodes a data signal.
The computer system 140 is one example of many possible computer systems which have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an I/O bus for the peripherals and one that directly connects the processor 148 and the memory 152 (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.
Network computers are another type of computer system that can be used with the present invention. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory 152 for execution by the processor 148. A Web TV system, which is known in the art, is also considered to be a computer system according to the present invention, but it may lack some of the features shown in
In addition, the computer system 140 is controlled by operating system software which includes a file management system, such as a disk operating system, which is part of the operating system software. One example of an operating system software with its associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Wash., and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux operating system and its associated file management system. The file management system is typically stored in the non-volatile storage 156 and causes the processor 148 to execute the various acts required by the operating system to input and output data and to store data in memory, including storing files on the non-volatile storage 156.
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention, in some embodiments, also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language, and various embodiments may thus be implemented using a variety of programming languages.
The streaming client 164 may be coupled to and accessible through the network 162. The streaming client 164 could be a software, firmware, or hardware module. Alternatively, the streaming client 164 could include some combination of software, firmware, or hardware components. The streaming client 164 may be part of a computer system, such as the computer system 140 (
The computer system 140 includes a processor 166, a memory 168, and a bus 170 that couples the processor 166 to the memory 168. The memory 168 may include both volatile memory, such as DRAM or SRAM, and non-volatile memory, such as magnetic or optical storage. The memory 168 may also include, for example, environment variables. The processor 166 executes code in the memory 168. The memory 168 includes a streaming server 172, a block request database 174, a prediction engine 176, and one or more streaming applications 178. Some or all of the programs, files, or data of the computer system 140 could be served as Web content, such as by the server computer 106 (
The streaming server 172 may be configured to serve data associated with a block of a streaming application, such as one of the streaming applications 178, in response to a request for the block. The block request database 174 may include data associated with block requests received from one or more streaming clients, such as the streaming client 164. The block request database 174 may include a block request log, which is updated with each or with a subset of block requests. The block request database 174 may be client-specific or generally used by all or a subset of all streaming clients from which block requests are received. The block request database 174 may be application-specific or generally associated with all or a subset of all of the streaming applications 178. The block request database 174 may include a block request history that has been derived from data associated with block requests received over time, from some original default values, or from data input by, for example, a user or software agent that administers the computer system 140. The block request database 174 may include parameters derived from individual block requests, a block request log, or a block request history.
The prediction engine 176 is configured to predict one or more blocks, if any, the streaming client 164 will request. The term “engine,” as used herein, generally refers to any combination of software, firmware, hardware, or other component that is used to effect a purpose. The prediction engine 176 may include an aggressiveness parameter (not shown). If the aggressiveness is high, the prediction engine 176 is more likely to make a prediction than if the aggressiveness is low. In an exemplary embodiment, the aggressiveness parameter is associated with a probability threshold. The probability threshold may be a cut-off probability that results in predictions being made for blocks that are determined to have a probability of being requested that exceeds the cut-off probability. In another exemplary embodiment, the prediction engine 176 may predict any block with a probability of being requested that is higher than the probability threshold. In these examples, it should be noted that the aggressiveness parameter is low (i.e., the probability threshold is low) when aggressiveness is high. Nevertheless, for the purposes of linguistic clarity, hereinafter, it is assumed that the aggressiveness parameter is high when aggressiveness is high. For example, if the aggressiveness parameter is associated with a threshold probability, x, then the value of the aggressiveness parameter may be thought of as 1−x, which means the aggressiveness parameter is high when aggressiveness is high. This is for the purposes of linguistic clarity, and should not be construed as a limitation as to how the aggressiveness parameter is implemented. It should also be noted that the aggressiveness parameter is not limited to a threshold probability.
When the prediction engine 176 makes a prediction, the streaming server 172 may communicate the prediction to the streaming client 164. The prediction may include identifying data for one or more blocks, each of which met aggressiveness criteria, such as by having a predicted probability of being requested that is higher than a probability threshold. Identifying data, as used herein, is data sufficient to enable a streaming client to make a request for one or more blocks that are associated with the identifying data. The identifying data may, for example, include a block ID associated with a block. This identifying data may facilitate predictive requests for blocks before the blocks are actually needed at the streaming client 164. In an exemplary embodiment wherein the identifying data is provided to a streaming client 164, the streaming client 164 may determine whether to request the block associated with streaming data. This may help prevent downloading streaming data that the streaming client 164 doesn't really want or need. For example, if the streaming server 172 predicts that a streaming client 164 will need streaming data associated with a first block, and sends streaming data associated with the first block, the streaming client 164 is unable to choose whether to receive the streaming data based on, for example, local factors. On the other hand, if the streaming client 164 receives identifying data, the streaming client 164 may determine whether it actually wants the streaming data. In an alternative embodiment, the streaming server 172 may sometimes serve streaming data associated with a predicted block right away, possibly without even receiving a request from the streaming client 164 for the predicted block.
The prediction engine 176 may give a weight to a number of blocks. For example, the prediction engine 176 may predict a first block that is more likely to be requested than a second block (a probability parameter). The streaming client 164 may first request the blocks with, for example, the highest probability of being requested. As another example, the prediction engine 176 may give greater weight to a first block over a second block if the prediction engine 176 predicts the first block will be requested sooner than the second block (a temporal parameter). As another example, the prediction engine 176 may give greater weight to a first block over a second block if the first block is larger than the second block (a size parameter). The prediction engine 176 may weigh parameters associated with the streaming client 164, as well. For example, if the streaming client 164 has a limited buffer size, the aggressiveness parameter may be set lower. As another example, if the download bandwidth is low, the prediction engine 176 may place more weight on temporal or size parameters. Alternatively, the streaming client 164 may manage block requests according to local conditions, while the prediction engine 176 acts the same for all or a subset of all streaming clients.
In operation, the streaming client 164 sends over the network 162 to the streaming server 172 a request for a block associated with a streaming application of the streaming applications 178. The streaming server 172, or some other component (not shown) of the computer system 140, logs the request. For the purposes of example only, the block request database 174 is treated as a block request log. However, in various embodiments, the block request database 174 could be derived from a block request log or from individual or groups of block requests that are not recorded in a log. In an exemplary embodiment, the block request database 174 includes parameters derived from previous block requests, or from default or initial settings, that aid in predicting subsequent block requests from the streaming client 164.
The prediction engine 176 uses data from the block request database 174 to predict a subsequent block request. The subsequent block request may be for, for example, a block from the same streaming application as the initial block request, from a DLL, from a data file, from a different executable file, or from any other file or application. The streaming server 172 serves streaming data associated with the requested block and identifying data associated with the predicted block to the streaming client 164. The streaming client 164 then decides whether to request the identified predicted block. For example, the streaming client 164 may already have data for the block associated with the identifying data in a local cache. If the streaming server 172 sends the data again, that is a waste of bandwidth and may slow down the execution of the streaming application. Since the streaming server 172 sends identifying data instead of streaming data, the streaming client 164 can, for example, check the local cache first, and request the streaming data if it is not already available in the local cache. In another embodiment, the streaming server 172 serves streaming data associated with the requested block and identifying data associated with one or more predicted blocks. The streaming client 164 then decides which of the identified blocks to request and, for example, in what order. Naturally, if the prediction engine 176 is correct in its prediction, the streaming client 164 will eventually request a predicted block in due course even if the streaming client 164 does not request the predicted block in response to receiving the identifying data.
When a streaming server sends data associated with a predicted block (second block) request along with data associated with a requested block (first block), the first and second block data may be thought of as a “large block” if they are queued for sending back-to-back. However, in order to queue the first and second blocks back-to-back, the streaming server would have to receive the request for the second block and queue the second block data before the streaming server was finished sending the first block data. When data is sent as a large block, the streaming server can have nearly continuous output. Large blocks can help to more fully utilize available bandwidth, since large data requests can fully “saturate the pipe.” This is in contrast to sequential requests for blocks, which may not saturate the pipe because of the pause between sending first block streaming data and receiving a request for and sending second block streaming data. Fully saturating the pipe can improve performance.
In some cases, a block may be made large initially. For example, if a streaming application is for a level-based game, a large block may include data associated with an entire level. When a request for the block is received, data associated with the entire level is returned as continuous output from the streaming server. Alternatively, large blocks can be built “on the fly” based on a first block request and predicted block requests. For example, if the streaming server sends identifying data for multiple predicted block requests piggybacked on a reply to a first block request, along with streaming data associated with the first block, the streaming client can consecutively request some or all of the multiple predicted blocks. If the requests are made in relatively rapid succession, the streaming server may queue streaming data associated with two predicted blocks more rapidly than the streaming server sends streaming data associated with one predicted block. In this way, the streaming server maintains a full queue and, accordingly, can keep the pipe saturated.
At times, a streaming client may rapidly request blocks in a strictly sequential manner. For example, if a sequence of blocks is associated with a video clip, the blocks are reasonably likely to be served, in order, one after the other. A streaming server may recognize a sequential pattern of block requests, either because the streaming server is provided with the pattern, or because the streaming server notices the pattern from block requests it receives over time. The streaming server may send the pattern to the streaming client in response to a block request that has been found to normally precede block requests for blocks that are identified in the pattern. Using the pattern, the streaming client may predictively request additional blocks in anticipation of the streaming application needing them. The streaming client may make these requests in relatively rapid succession, since each request can be made using the pattern the streaming client received from the streaming server. This may result in output pipe saturation at the streaming server. The streaming client may or may not wait for a reply to each request. Predictively requested blocks may be stored in a local cache until they are needed. The parameters that control recognition of the pattern, as well as how aggressive the read-ahead schedule should be, can be independently specified at the file, file extension, directory, and application level. In addition, it can be specified that some blocks are predictively downloaded as soon as a file is opened (even before seeing a read) and that the open call itself should wait until the initial blocks have been downloaded. In an exemplary embodiment, the pattern includes identifying data for each block represented in the pattern. The patterns may be included in a block request database.
In an alternative embodiment, the streaming server may provide the streaming client with one or more patterns as a pattern database. The streaming server may or may not provide the pattern database when the streaming client first requests streaming of a streaming application associated with the pattern database. The streaming client may use the pattern database to predict which blocks to request based on block requests it intends to make. For example, if a first block request is associated with blocks in a pattern in the pattern database, the streaming client requests the first block and each of the blocks in the pattern in succession. The pattern database may be included in a block request database.
In operation, the input node 219 receives a block request from a streaming client (not shown). The input node 219 provides the block request to the streaming server 220. The streaming server 220 logs the block request in the request log 222. The streaming server obtains a prediction from the prediction engine 224. The logging of the request and the obtaining of a prediction need not occur in any particular order. For example, the streaming server 220 could obtain a prediction from the prediction engine 224 prior to (or without consideration of) the logged block request.
The prediction engine 224 checks the request log 222, performs calculations to represent data in the request log 222 parametrically, and updates the parameters of the block request database 226. The prediction engine 224 checks the parameters of the block request database 226 in order to make a prediction as to subsequent block requests from the streaming client. The checking of the request log and checking of the parameters need not occur in any particular order. For example, the prediction engine 224 could check the parameters prior to checking the request log and updating the parameters. The prediction engine 224 could check the request log and update the parameters as part of a routine updating procedure, when instructed to update parameters by a user or agent of the system 600, or in response to some other stimulus, such as an access to the streaming application 228. Accordingly, the checking of the log request and updating of the parameters may be thought of as a separate, and only indirectly related, procedure vis-à-vis the checking of parameters to make a prediction. The prediction may be in the form of one or more block IDs, identifying data for one or more blocks, a pattern, or any other data that can be used by a streaming client to determine what blocks should be requested predictively.
When the streaming server 220 obtains the prediction, the streaming server 220 optionally accesses the requested block of the streaming application 228. Obtaining the prediction and accessing the requested block need not occur in any particular order and could overlap. The prediction provided to the streaming server 220 may or may not be modified by the streaming server 220. For example, the prediction may include data that is used to “look up” identifying data. In this case, the portion of the streaming server 220 that is used to look up identifying data may be referred to as part of the prediction engine 224.
Access to the requested block of the streaming application 228 is optional because the streaming server 220 could simply return an identifier of the predicted block without sending the predicted block itself. Indeed, it may be more desirable to send only a prediction because the recipient of the prediction (e.g., a streaming client) may already have received the block. If the recipient already received the block, and the block remains cached, there is probably no reason to send the block again. Accordingly, the streaming server, upon receiving the prediction, would not request the predicted block again. The streaming server 220 can be referred to as obtaining identifying data from the prediction engine 224, where the identifying data can be used by, for example, the streaming client when making one or more predictive block requests.
The streaming server 220 provides data associated with the requested block, such as streaming data, and the prediction, such as identifying data, to the output node 230. The data is sent from the output node 230 to, for example, a streaming client (not shown). In an exemplary embodiment, the prediction is piggy-backed on the reply that includes the, for example, streaming data. In another exemplary embodiment, the prediction could be sent separately, either before, at approximately the same time as, or after the reply that includes the, for example, streaming data. In an alternative embodiment, the streaming server 220 could access a predicted block of the streaming application 228 and send a reply that includes streaming data associated with the predicted block as part of the reply that includes the requested block data. Or, the streaming server 220 could send streaming data associated with the predicted block separately, before, at the same time as, or after sending the reply that includes the requested block data.
A prediction may or may not always be provided by the prediction engine 224. If no prediction is provided to the streaming server 220, the streaming server may simply provide streaming data associated with the requested block. In an exemplary embodiment, the prediction engine 224 may fail to provide a prediction if it does not have sufficient data to make a prediction. Alternatively, the prediction engine 224 may provide a prediction only if it meets a certain probability. For example, an aggressiveness parameter may be set to a cut-off threshold of, e.g., 0.5. If predictive certainty for a block does not meet or exceed the cut-off threshold, the prediction engine 224 may not provide the prediction for the block to the streaming server 220.
Current block request for block 3: As illustrated in the request log 232, a block request for block 5 (the second block request) immediately follows the request for block 3 (the first block request). Since the second block request follows the request for block 3, a prediction can be made about whether the current block request (for block 3) will be followed by a request for block 5. Since, for the purposes of example, the parameters are derived only from the request log 232 (and no other data is considered), it might be assumed that a request for block 5 is 100% certain. The predicted block parameters array for block 3 is [(5, 1.0)]. This can be interpreted to mean, following a request for block 3, the probability of a request for block 5 is 1.0. Of course, this is based on a small data sample and is, therefore, subject to a very large error. However, over time the probability may become more accurate.
Current block request for block 4: As illustrated in the request log 232, a block request for block 4 has not been made. Accordingly, no prediction can be made.
Current block request for block 5: For reasons similar to those given with respect to the request for block 3, the predicted parameters array for block 5 is [(8, 1.0)].
Current block request for block 6: As illustrated in the request log 232, a block request for block 6 has been made before, but it was the last block requested (none follow). Accordingly, no prediction can be made.
Current block request for block 7: For reasons similar to those given with respect to the request for block 3, the predicted parameters array for block 5 is [(8, 1.0)].
Current block request for block 8: As illustrated in the request log 232, a block request for block 8 has been made twice before. The block request following a request for block 8 was 3 one time and 6 the other time. It may be assumed, for exemplary purposes, that the request for block 3 or 6 is equally probable. Accordingly, the predicted block parameters array for block 8 is [(3, 0.5), (6, 0.5)]. This can be interpreted to mean, following a request for block 8, the probability of a request for block 3 is 0.5 and the probability of a request for block 6 is 0.5. Since the requests for blocks 3 and 6 are considered equally probable, data associated with both block 3 and block 6 may be included in a reply. Alternatively, neither may be used. Also, an aggressiveness parameter may be set that requires a higher than 0.5 probability in order to be predicted.
Other factors could be considered in “breaking a tie” between equally probable block predictions, such as blocks 3 and 6, which are predicted to follow block 8 in
In this example, a prediction was made as to which block was requested following a current block request, though in alternative examples, predictions could be made as to the next requested block, the one after, any other subsequent block request, or some combination thereof. Also, the predicted block parameters are represented in an array, but any data structure that captures the relevant information would be acceptable.
In an embodiment, time-related predictive parameters may be ignored if they are too high. The threshold value over which a time difference would result in a block request being ignored may be referred to as a temporal aggressiveness parameter. For example, if a temporal aggressiveness parameter is 1 hour, then the predicted block parameters array for block 8 could be rewritten as [(3, 1.0, 0:05:20)]. That is, the values related to block 6 are ignored since block 6 was received more than 1 hour after block 8, according to the request log 236. Alternatively, the predicted block parameters array for block 8 could be rewritten as [(3, 0.5, 0:05:20)], which is basically the same, but the probability is not recalculated when the values related to block 6 are ignored. Similarly, the predicted block parameters array for block 3 could be rewritten as [ ], since there are no block requests within 1 hour (the temporal aggressiveness threshold, in this example) of the block request for block 3.
In an alternative embodiment, a prediction engine could keep chaining predicted blocks back through the prediction engine to get subsequent predicted blocks, under the assumption that the “first round” predicted blocks were correct. The probabilities of subsequent predicted blocks may be multiplied by the probability of the original predicted block to accurately get a predicted probability for the secondary (ternary, etc) blocks. This could continue until the probabilities fell below an aggressiveness threshold. A limit may be placed on the max number of predictions returned. It should be noted that in the case of a long chain of blocks that follow each other with probability 1.0, the first request may return a list of all subsequent blocks in the chain, which a streaming client can then “blast request” to keep the pipeline at the streaming server full.
In an embodiment, the times are not actually recorded, as depicted in
A session may be thought of in terms of the block requests made over the course of streaming a streaming application. For example, in the five sessions depicted in the log request 244 of
In some embodiments, it may be desirable to utilize a higher order probability. For example, if the streaming application is a game program that starts in a room with four doors that lead to four different rooms, each of which is associated with multiple block requests, the multiple blocks associated with each of the four different rooms may be equally likely (about 25% each). If a door is selected, each of the multiple blocks associated with each of the doors (even those not taken) may be about 25%. By using a first-order predictor, once we see the first block request for one of the rooms, the subsequent blocks for that room will have first-order probabilities near 100%, and so the multiple blocks for that room can be predictively downloaded.
Given the request log 248, the probability that a second block will be requested following a first block request can be determined for one or more sessions. The block request database 250 is organized to show the first-order probability for a block, given the context of another block. The block request database 250 is not intended to illustrate a data structure, but rather to simply illustrate, for exemplary purposes, first-order probability. The probability of a block request (for the block in the Block column) is depicted under the first-order probability for each block. For example, the first-order probability of a block request for Block 3 is 1.0 with Block 4 as context, 0 with Block 5 as context, 0 with Block 6 as context, 1.0 with Block 7 as context, and 0.8 with Block 8 as context. These probabilities are derived as follows. As is shown in the request log 248, when blocks 5 or 6 are requested (Session 3), block 4 is not requested. Accordingly, the first-order probability for block 3 with either block 5 or 6 as context is 0. When blocks 4 or 7 have been requested (Sessions 2 and 1, respectively), block 3 is also requested. Accordingly, the first-order probability for block 3 with block 4 as context is 1.0. When block 8 has been requested (all five sessions), block 3 is also requested 4 out of 5 times. Accordingly, the first-order probability for block 3 with block 8 as context is 0.8. First-order probabilities for each block can be derived in a similar manner. The probabilities are shown in the block request database 250.
Second- and higher-order probabilities can be determined in a similar manner to that described with reference to
In an exemplary embodiment, a streaming server can use the zero- or higher order probabilities to determine which blocks have probabilities that exceed a “predictive download aggressiveness” parameter and piggyback those block IDs, but not the block data itself, onto the block data returned to a streaming client. The client can then decide which blocks it will predictively download, based on local factors. Local factors may include client system load, contents of the local disk cache, bandwidth, memory, or other factors.
It should be noted that in certain embodiments, it may not be possible to incorporate all incoming block requests into the request log because block requests are being “filtered” by the local disk cache. This may result in the request log including only those block requests for blocks that weren't in the local disk cache, which will throw the predictors off. Accordingly, in an embodiment, a streaming server may indicate to a streaming client that the server is interested in collecting prediction data. In this case, the streaming client would send a separate data stream with complete block request statistics to the streaming server. In this example, the separate data stream may include all actual block requests made by the application, regardless of whether that request was successfully predicted or is stored in a local cache of the streaming client.
The flowchart continues at module 254-1 with receiving block requests. The streaming server may receive the block requests from the streaming client. The flowchart continues at module 256-1 with sending data associated with the block requests, including predictions, if any. The flowchart continues at decision point 258-1, where it is determined whether the session is over. If the session is not over, the flowchart continues from module 254-1 for another block request. Otherwise, if the session is over, the flowchart ends for modules 254-1 to 258-1.
The flowchart continues at module 254-2 with receiving block request statistics, including block requests for blocks stored in a local disk cache. Module 254-2 may or may not begin after module 258-1 ends. Module 254-2 may or may not continue after module 258-1 ends. The flowchart continues at module 256-2 with updating predictive parameters using the block request statistics. The predictive parameters may be used at module 256-1 to provide predictions. The flowchart continues at decision point 258-2, where it is determined whether the session is over. If the session is not over, the flowchart continues from module 254-2 for more block request statistics. Otherwise, if the session is over, the flowchart ends for modules 254-2 to 258-2.
In another embodiment, a streaming client may indicate to a streaming server that the streaming client is interested in receiving predictive block data IDs. Then the streaming server would piggyback the IDs, as described previously.
In another embodiment, the streaming server may send the block request database to the client along with an initial token file so that the client can do all of the predictive calculations.
In another embodiment, the streaming client may collect predictive data locally and then send the data to the streaming server at the end of the session.
In an alternative embodiment, a streaming server can maintain a block request database that keeps track of “runs.” Runs are sets of blocks for which the block requests occur closely spaced in time. For example, if a sequence of blocks is requested within, say, 0.5 second of a preceding block request in the sequence, the sequence of blocks may be referred to as a run. Runs can be used to efficiently utilize memory resources by recording probabilities on the run level instead of per block. Runs can also be used to reduce the amount of predictive download data. For example, for a level-based game, a user may download a first block, then the rest of the game will be predictively downloaded for each level, since the probabilities of downloading each level are, for the purposes of this example, nearly 100%.
By keeping track of runs, after the first level has been downloaded, predictive downloads can be “shut off” until the start of blocks for the second level begin. For example, if the blocks at the beginning of the run, which trigger or signal the run, are detected, the block IDs for the rest of the run may be sent to the streaming client, who then chain requests them. However, those subsequent block requests do not trigger any further run. So, the predictive downloads cause the blocks in the middle of a run to not act as a triggering prefix of another run; no further predictions are made from the middle of a run.
When a run is stored in the block request database, each block of the run may be downloaded in succession without requiring individual predictions. In an alternative embodiment, each successive block of a run may be given an effective probability of 1.0, which guarantees favorable predictive treatment regardless of the aggressiveness threshold (assuming the threshold allows for some prediction). In yet another alternative, a streaming client may receive an identifier for the run and request successive blocks in the run, using the identifier to identify the successive blocks.
While this invention has been described in terms of certain embodiments, it will be appreciated by those skilled in the art that certain modifications, permutations and equivalents thereof are within the inventive scope of the present invention. It is therefore intended that the following appended claims include all such modifications, permutations and equivalents as fall within the true spirit and scope of the present invention; the invention is limited only by the claims.
This application claims priority to U.S. Provisional Application 60/621,178, entitled SYSTEM AND METHOD FOR PREDICTIVE STREAMING, filed Oct. 22, 2004, which is hereby incorporated by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4796220 | Wolfe | Jan 1989 | A |
| 5063500 | Shorter | Nov 1991 | A |
| 5109413 | Comeford et al. | Apr 1992 | A |
| 5210850 | Kelly et al. | May 1993 | A |
| 5293556 | Hill et al. | Mar 1994 | A |
| 5442791 | Wrabetz et al. | Aug 1995 | A |
| 5495411 | Ananda | Feb 1996 | A |
| 5548645 | Ananda | Aug 1996 | A |
| 5666293 | Metz et al. | Sep 1997 | A |
| 5696965 | Dedrick | Dec 1997 | A |
| 5701427 | Lathrop | Dec 1997 | A |
| 5706440 | Compliment et al. | Jan 1998 | A |
| 5715403 | Stefik | Feb 1998 | A |
| 5764906 | Edelstein et al. | Jun 1998 | A |
| 5778395 | Whiting et al. | Jul 1998 | A |
| 5805809 | Singh et al. | Sep 1998 | A |
| 5809144 | Sirbu et al. | Sep 1998 | A |
| 5822537 | Katseff et al. | Oct 1998 | A |
| 5835722 | Bradshaw et al. | Nov 1998 | A |
| 5838910 | Domenikos et al. | Nov 1998 | A |
| 5878425 | Redpath | Mar 1999 | A |
| 5881232 | Cheng et al. | Mar 1999 | A |
| 5892915 | Duso et al. | Apr 1999 | A |
| 5895454 | Harrington | Apr 1999 | A |
| 5903721 | Sixtus | May 1999 | A |
| 5903732 | Reed et al. | May 1999 | A |
| 5903892 | Hoffert et al. | May 1999 | A |
| 5905868 | Baghai et al. | May 1999 | A |
| 5909545 | Frese et al. | Jun 1999 | A |
| 5911043 | Duffy et al. | Jun 1999 | A |
| 5918015 | Suzuki et al. | Jun 1999 | A |
| 5923885 | Johnson | Jul 1999 | A |
| 5933603 | Vahalia et al. | Aug 1999 | A |
| 5933822 | Braden-Harder et al. | Aug 1999 | A |
| 5943424 | Berger et al. | Aug 1999 | A |
| 5948062 | Tzelnic et al. | Sep 1999 | A |
| 5948065 | Eilert et al. | Sep 1999 | A |
| 5949877 | Traw et al. | Sep 1999 | A |
| 5953506 | Kalra et al. | Sep 1999 | A |
| 5960411 | Hartman et al. | Sep 1999 | A |
| 5963944 | Admas | Oct 1999 | A |
| 5973696 | Arganat et al. | Oct 1999 | A |
| 5987454 | Hobbs | Nov 1999 | A |
| 6014686 | Elnozahy et al. | Jan 2000 | A |
| 6018619 | Allrad et al. | Jan 2000 | A |
| 6026166 | LeBourgeois | Feb 2000 | A |
| 6028925 | Van Berkum et al. | Feb 2000 | A |
| 6038379 | Fletcher et al. | Mar 2000 | A |
| 6038610 | Belfiore et al. | Mar 2000 | A |
| 6047323 | Krause | Apr 2000 | A |
| 6061738 | Osaku et al. | May 2000 | A |
| 6065043 | Domenikos et al. | May 2000 | A |
| 6081842 | Shachar et al. | Jun 2000 | A |
| 6085186 | Christianson et al. | Jul 2000 | A |
| 6085193 | Malkin et al. | Jul 2000 | A |
| 6088705 | Lightstone | Jul 2000 | A |
| 6094649 | Bowen et al. | Jul 2000 | A |
| 6099408 | Schneier et al. | Aug 2000 | A |
| 6101482 | DiAngelo et al. | Aug 2000 | A |
| 6101491 | Woods | Aug 2000 | A |
| 6108420 | Larose et al. | Aug 2000 | A |
| 6138271 | Keeley | Oct 2000 | A |
| 6154878 | Saboff | Nov 2000 | A |
| 6157948 | Inoue et al. | Dec 2000 | A |
| 6167510 | Tran | Dec 2000 | A |
| 6185608 | Hon et al. | Feb 2001 | B1 |
| 6192398 | Hunt et al. | Feb 2001 | B1 |
| 6192408 | Vahalia et al. | Feb 2001 | B1 |
| 6219693 | Napolitano et al. | Apr 2001 | B1 |
| 6226665 | Deo et al. | May 2001 | B1 |
| 6253234 | Hunt et al. | Jun 2001 | B1 |
| 6275496 | Burns et al. | Aug 2001 | B1 |
| 6278992 | Curtis et al. | Aug 2001 | B1 |
| 6282712 | Davis et al. | Aug 2001 | B1 |
| 6298356 | Jawahar et al. | Oct 2001 | B1 |
| 6301605 | Napolitano et al. | Oct 2001 | B1 |
| 6301629 | Sastri et al. | Oct 2001 | B1 |
| 6311221 | Raz et al. | Oct 2001 | B1 |
| 6330561 | Cohen et al. | Dec 2001 | B1 |
| 6347398 | Parthasarathy et al. | Feb 2002 | B1 |
| 6356946 | Clegg et al. | Mar 2002 | B1 |
| 6370686 | Delo et al. | Apr 2002 | B1 |
| 6374402 | Schmeidler et al. | Apr 2002 | B1 |
| 6418554 | Delo et al. | Jul 2002 | B1 |
| 6418555 | Mohammed | Jul 2002 | B2 |
| 6449688 | Peters et al. | Sep 2002 | B1 |
| 6453334 | Vinson et al. | Sep 2002 | B1 |
| 6457076 | Cheng et al. | Sep 2002 | B1 |
| 6510458 | Berstis et al. | Jan 2003 | B1 |
| 6510462 | Blumenau | Jan 2003 | B2 |
| 6510466 | Cox et al. | Jan 2003 | B1 |
| 6574618 | Eylon et al. | Jun 2003 | B2 |
| 6584507 | Bradley et al. | Jun 2003 | B1 |
| 6587857 | Carothers et al. | Jul 2003 | B1 |
| 6598125 | Romm | Jul 2003 | B2 |
| 6601103 | Goldschmidt Iki et al. | Jul 2003 | B1 |
| 6601110 | Marsland | Jul 2003 | B2 |
| 6609114 | Gressel et al. | Aug 2003 | B1 |
| 6622137 | Ravid et al. | Sep 2003 | B1 |
| 6622171 | Gupta et al. | Sep 2003 | B2 |
| 6636961 | Braun et al. | Oct 2003 | B1 |
| 6687745 | Franco et al. | Feb 2004 | B1 |
| 6694510 | Williems | Feb 2004 | B1 |
| 6697869 | Mallart et al. | Feb 2004 | B1 |
| 6711619 | Chanderamohan et al. | Mar 2004 | B1 |
| 6735631 | Oehrke et al. | May 2004 | B1 |
| 6757708 | Craig et al. | Jun 2004 | B1 |
| 6757894 | Eylon et al. | Jun 2004 | B2 |
| 6763370 | Schmeidler et al. | Jul 2004 | B1 |
| 6772209 | Chernock et al. | Aug 2004 | B1 |
| 6779179 | Romm et al. | Aug 2004 | B1 |
| 6785768 | Peters et al. | Aug 2004 | B2 |
| 6810525 | Safadi et al. | Oct 2004 | B1 |
| 6816909 | Chang et al. | Nov 2004 | B1 |
| 6816950 | Nichols | Nov 2004 | B2 |
| 6832222 | Zimowski | Dec 2004 | B1 |
| 6836794 | Lucowsky et al. | Dec 2004 | B1 |
| 6854009 | Hughes | Feb 2005 | B1 |
| 6891740 | Williams | May 2005 | B2 |
| 6918113 | Patel et al. | Jul 2005 | B2 |
| 6925495 | Hedge et al. | Aug 2005 | B2 |
| 6938096 | Greschler et al. | Aug 2005 | B1 |
| 6959320 | Shah et al. | Oct 2005 | B2 |
| 7028305 | Schaefer et al. | Apr 2006 | B2 |
| 7043524 | Shah et al. | May 2006 | B2 |
| 7051315 | Artiz et al. | May 2006 | B2 |
| 7062567 | Benitez et al. | Jun 2006 | B2 |
| 7093077 | Cooksey et al. | Aug 2006 | B2 |
| 20010037399 | Eylon et al. | Nov 2001 | A1 |
| 20010037400 | Raz et al. | Nov 2001 | A1 |
| 20010044850 | Raz et al. | Nov 2001 | A1 |
| 20020019864 | Mayer | Feb 2002 | A1 |
| 20020042833 | Hendler et al. | Apr 2002 | A1 |
| 20020078170 | Brewer et al. | Jun 2002 | A1 |
| 20020078203 | Greschler et al. | Jun 2002 | A1 |
| 20020083183 | Pujare et al. | Jun 2002 | A1 |
| 20020083187 | Sim et al. | Jun 2002 | A1 |
| 20020087717 | Artzi et al. | Jul 2002 | A1 |
| 20020087883 | Wohlgemuth et al. | Jul 2002 | A1 |
| 20020091763 | Shah et al. | Jul 2002 | A1 |
| 20020138640 | Raz et al. | Sep 2002 | A1 |
| 20020156911 | Croman et al. | Oct 2002 | A1 |
| 20020157089 | Patel et al. | Oct 2002 | A1 |
| 20020161908 | Benitez et al. | Oct 2002 | A1 |
| 20020174215 | Schaefer | Nov 2002 | A1 |
| 20030004882 | Holler et al. | Jan 2003 | A1 |
| 20030009538 | Shah et al. | Jan 2003 | A1 |
| 20030056112 | Vinson et al. | Mar 2003 | A1 |
| 20030140160 | Raz et al. | Jul 2003 | A1 |
| 20040230971 | Rachman et al. | Nov 2004 | A1 |
| 20040268361 | Schaefer | Dec 2004 | A1 |
| 20050010670 | Greschler et al. | Jan 2005 | A1 |
| 20050193139 | Vinson et al. | Sep 2005 | A1 |
| 20060048136 | De Vries et al. | Mar 2006 | A1 |
| 20060123185 | De Vries et al. | Jun 2006 | A1 |
| 20060136389 | Cover et al. | Jun 2006 | A1 |
| Number | Date | Country |
|---|---|---|
| PCTUS2006010637 | Mar 2006 | WO |
| PCTUS2006010904 | Mar 2006 | WO |
| WO 2006022745 | Mar 2006 | WO |
| WO 2006047133 | May 2006 | WO |
| WO 2006055445 | May 2006 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20060106770 A1 | May 2006 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60621178 | Oct 2004 | US |
