Feedback for downlink sensitivity

A method, system, and medium are provided for managing bandwidth associated with a communication session characterized by a plurality of data packets being transmitted from a sender to a receiver. The receiver can include functions that monitor communication sessions and determine bandwidth adjustments corresponding thereto for optimizing the user's experience. The receiver can communicate feedback messages to senders that include requests for bandwidth adjustments. According to embodiments, senders can include well-known feedback listening ports through which feedback messages are received, enabling out-of-band user experience optimization.

SUMMARY

Embodiments of the invention are defined by the claims below, not this summary. An overview of embodiments of the invention is provided here for that reason.

In a first embodiment, a set of computer-executable instructions provides an illustrative method of managing bandwidth corresponding to one or more communication sessions associated with a receiver on a computing device. Embodiments of the illustrative method include referencing a plurality of active applications that correspond to communication sessions and determining that a first application has focus. Bandwidth requirement amounts and bandwidth usage amounts corresponding to a first communication session can be determined and compared. In an embodiment of the illustrative method, feedback is communicated to a sender associated with the first communication session. The feedback can include, for example, a request to adjust the bandwidth associated with the first communication session.

In a second embodiment, a set of computer-executable instructions provides an illustrative method of managing a plurality of communication sessions associated with a receiver. According to embodiments of the illustrative method, a user-experience manager on the receiver can identify a plurality of active applications, where each application is associated with a communication session. Embodiments of the illustrative method further include determining that a first application has focus and a second application does not have focus. Bandwidth usage and requirement amounts corresponding to the first and second sessions can be determined and an optimizing decision can be made regarding whether to adjust one of the bandwidths. In embodiments of the illustrative method, the receiver communicates feedback to one or more senders to request adjustments of bandwidth in accordance with the optimizing decision.

According to a third embodiment, a system for use in a data packet sender is provided, which facilitates managing a bandwidth associated with sending data packets to a receiver during a communication session. Embodiments of the illustrative system include a media out port through which the sender transmits data packets, a feedback listening port through which the sender receives feedback messages from the receiver, and a bandwidth manager that adjusts data packet transmission rates, packet sizes, or the like according to the feedback.

DETAILED DESCRIPTION

Throughout the description of embodiments of the invention, several acronyms and shorthand notations are used to aid the understanding of certain concepts pertaining to the associated system and services. These acronyms and shorthand notations are intended to help provide an easy methodology of communicating the ideas expressed herein and are not meant to limit the scope of the invention.

Embodiments of the invention may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program modules, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program modules including routines, programs, objects, components, data structures, etc., refer to code that perform particular tasks or implement particular abstract data types. Embodiments of the invention may be practiced in a variety of system configurations, including handheld devices, consumer electronics, general-purpose computers, more specialty computing devices, and the like. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote-processing devices that are linked through a communications network. Computer-readable media include both volatile and nonvolatile media, removable and nonremovable media, and contemplates media readable by a database, a switch, and various other network devices, which are non-transitory in nature. By way of example, and not limitation, computer-readable media comprise media implemented in any method or technology for storing information. Examples of stored information include computer-useable instructions, data structures, program modules, and other data representations. Media examples include, but are not limited to, information-delivery media, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVD), holographic media or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage, and other magnetic storage devices. These technologies can store data momentarily, temporarily, or permanently.

An exemplary operating environment in which various embodiments of the invention may be implemented is described below in order to provide a general context. Referring initially toFIG. 1in particular, an exemplary operating environment for implementing embodiments of the invention is shown and designated generally as computing device100. Computing device100is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing device100be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

Memory112includes computer-storage media in the form of volatile and/or nonvolatile memory. The memory112may be removable, nonremovable, or a combination thereof. Exemplary memory devices include solid-state memory, hard drives, optical-disc drives, etc. Computing device100includes one or more processors114that read data from various entities such as memory112or I/O components120. Presentation component(s)116present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, etc.

Turning toFIG. 2, an exemplary network environment200for implementing embodiments of the invention is shown. Network environment200includes a sender210and receivers212and214. Sender210is an entity, network component, software module, hardware device, or the like that sends data packets to receivers212and214. Although not illustrated inFIG. 2, it will be understood that sender210can communicate with receivers212and214through one or more networks. The networks can be any kind of suitable network such as, for example, a local area network (LAN), a wide area network (WAN), the Internet, or a combination of networks. Network environment200is merely an example of one suitable network environment and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention. Neither should network environment200be interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein.

Sender210can be any kind of device, server, or software module that is capable of sending data packets to receivers212and214. For example, in an embodiment, sender210is a streaming server, often referred to simply as a “streamer,” that provides data services to receivers212and214. For instance, in some embodiments, sender210can be a server that provides media services such as multimedia, video, audio, or the like. In some embodiments, sender210is hosted by a single machine such as, for example, a computing device100. In other embodiments, sender210can be distributed across a number of machines.

In an embodiment, sender210transmits data packets to receivers212and214according to a standard transport-layer protocol such as, for example, user datagram protocol (UDP). In other embodiments, sender210can communicate with receivers212and214using other types of connectionless protocols.

With continued reference toFIG. 2, receivers212and214can be any suitable entity that receives data packets from sender210. For example, in an embodiment, receivers212and214are clients or software modules hosted by a user's computing device. In other embodiments, each receiver212and214is a computing device such as, for example, computing device100, discussed above with reference toFIG. 1. That is, receivers212and214can be located on any number of types of devices such as, for example, a personal computer, a laptop computer, a wireless telephone, a personal digital assistant (PDA), a cellular phone, and the like. Additionally, neither sender210nor receivers212and214should be interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein.

As depicted inFIG. 2, sender210includes codec216, media out ports218,220,222, and224, session manager226, bandwidth manager228, and feedback listening port230. Using any number of various types of codec216, sender210encodes and transmits, via media out ports218,220,222, and224streams of data packets to receivers212and214. In some embodiments, sender210may transmit data packets to only one receiver212or214, while in other embodiments, sender210transmits data packets to a number of receivers212,214. In some embodiments, sender210transmits the same or similar data packets to each of receivers212and214and in other embodiments, sender210can transmit unique data packets to each of receivers212and214. Any combination of the above and other configurations are considered to be within the ambit of embodiments of the invention.

Codec216can include encoders, decoders, encoder/decoders, and the like and can be adapted for generating various data according to any number of various standards such as, for example, standards developed by the Moving Picture Experts Group (MPEG), Joint Photographic Experts Group (JPEG), formats such as Windows Media Video (WMV), and the like. In some embodiments, as illustrated inFIG. 2, sender210can include a set of codecs216for each media out port218,220,222, and224. In other embodiments, sender210can include one set of codecs216that service all of the media out ports218,220,222, and224. In further embodiments, any number of layers of codecs, filters, and other functions and components can be used by sender210during communication sessions (e.g., UDP sessions) with receivers212and214. Additionally, it should be understood that media out ports218,220,222, and224can, in some embodiments, be integrated within a single port. In other embodiments, sender210can include a variety of media out ports218,220,222, and224. Also, media out ports218,220,222, and224are not limited to physical port connections, but can also include logical ports such as, for example, identifiers that correspond to particular functions or types of media, logically addressable data communication destinations, and the like.

Session manager226can include servers, software modules, firmware, and other components and modules that perform various functions associated with codec216and media out ports218,220,222, and224. According to various embodiments of the invention, session manager226organizes and manages communication sessions in which sender210transmits data packets to, for example, receivers212and214. For instance, in some embodiments, session manager226interfaces with codec216and media out ports218,220,222, and224to coordinate the encoding and transmitting of streams of data packets to receivers212and214. The data packets can embody various types of media such as data files, email service, video, multimedia, audio conferencing, streaming radio stations, and the like. Session manager226can facilitate the retrieval of content for transmission to receivers212and214. In embodiments, sender210can include storage modules, databases, and the like for maintaining content to provide to receivers212and214. In other embodiments, sender210can retrieve content from other sources such as, for example, content servers, other networks, other devices, application servers, and the like.

According to embodiments of the invention, session manager226maintains information associated with communication sessions in which sender210transmits data packets to a receiver212,214. In some embodiments, session manager226hosts a database, table, file, or other data storage component that contains various types of data. For example, in embodiments, session manager226can record information corresponding to a communication session. Such information can include addressing information, identification information, information about bandwidth usage amounts related to various communication sessions, and the like. In one embodiment, for example, sender210is a UDP streamer and session manager226maintains socket identifiers corresponding to each of the UDP sessions in which sender210is involved. Socket identifiers can include addressing information such as, for example, internet protocol (IP) addresses, port numbers, packet transmission rates, information about packet size, and the like.

In embodiments of the invention, session manager226identifies communication sessions according to identification information, addressing information, and the like. For example, in one embodiment, session manager226uses a socket identification (e.g., an IP address corresponding to the sender210and a port number corresponding to the media out port being used in the session) to identify a communication session. In other embodiments, session manager226can use other identifiers as well. According to some embodiments, session manager226identifies communication sessions using tuples. A tuple is a discrete set of data that includes addressing information associated with the parties involved in a communication session. In embodiments, a tuple can include a socket identification corresponding to sender210and a socket identification corresponding to receiver212or214. That is, for example, a tuple might include an IP address and port number associated with sender210and an IP address and port number associated with receiver212or214. In various embodiments of the invention, session manager226can differentiate between communication sessions using tuples because a different media out port218,220,222,224is used for each session. In other embodiments, sender210may use the same media out port218,220,222, or224for all sessions, but differentiates between sessions, because the socket identification (e.g., IP address and port number) associated with each receiver212and214will be different.

With reference toFIG. 2, session manager226can receive feedback information by way of feedback listening port230. Feedback information is communicated to sender210by receivers212and214in the form of feedback messages. The structure of feedback messages is described in more detail below, with reference toFIG. 4B. In various embodiments of the invention, feedback messages include data packets that contain an instruction to increase or decrease a packet transmission rate, bandwidth, or packet size associated with a particular communication session. In embodiments, the communication session is identified according to its corresponding tuple. Additionally, feedback messages can include an identifier associated with the active application on the receiver212or214that is consuming the data packet stream. In this manner, receiver212or214can send feedback messages to sender210that include an identification of the tuple corresponding to the session with which the feedback message is associated so that the sender210can determine which data packet stream to adjust.

According to various embodiments of the invention, session manager226receives feedback messages communicated from receiver212or214via feedback listening port230, parses the messages, and performs operations in response to the messages. For instance, in embodiments, a feedback message can include a request to decrease or increase a bandwidth associated with a communication session. Session manager226can cooperate with bandwidth manager228to adjust the bandwidth of the session accordingly. Bandwidth manager228can include independent logic for managing bandwidth associated with a number of communication sessions. In other embodiments, bandwidth manager228includes modules for adjusting the bandwidth based on logic processed by session manager226. Bandwidth manager228can adjust bandwidth in any number of ways. For example, in one embodiment, bandwidth manager228can intercept and eliminate a certain number of data packets from a stream of data packets being passed from codec216to one of the media out ports218,220,222, or224, thereby reducing the number of data packets being sent during any given period of time. In other words, bandwidth manager228can adjust the rate of data packet transmission. In some embodiments, bandwidth manager228can increase the number of data packets being sent during any period of time by retrieving more data packets from codec216, by copying selected data packets, and the like.

In further embodiments, bandwidth manager228can adjust the speed at which data packets are sent or the size of data packets. For example, in some embodiments, bandwidth manager228can independently, or upon instructions from session manager226, select a codec216for use in a communication session among a number of available codecs216. In this manner, sender210can change the data format and/or data packet size to satisfy bandwidth adjustment requests. In other embodiments, bandwidth manager228can include codecs, filters, and the like for affecting various types of adjustments to bandwidth associated with communication sessions.

According to various embodiments of the invention, feedback listening port230is a generic, or “well-known” port, that is configured to listen for feedback messages that include an identification of the feedback listening port230in their headers. A “well-known” port is a port that is established for a particular purpose, and is generally usable by any device that attempts to communicate with the sender210. That is, in embodiments, feedback listening port230is configured to listen for and receive feedback messages from a number of receivers212and214. In some embodiments, any receiver that sends a feedback message to sender210sends the message to feedback listening port230. In other embodiments, groups or classes of receivers212,214send feedback messages to assigned feedback listening ports230. For example, in an embodiment, sender210might provide several services such as “real-time” multiplayer games, streaming video, and voice over IP (VoIP) to receivers212and214. Sender210can have a feedback listening port230for each service, one feedback listening port230for all of the services, or any other combination or configuration suitable for facilitating receipt of feedback messages from receivers212and214. In other embodiments, for example where sender210is a UDP streamer, feedback listening port230can be an assigned port number that is used by any sender210that is configured to receive feedback messages from receivers212and214.

With continued reference toFIG. 2, receiver212includes media in port232and feedback port234and, similarly, receiver214includes media in port236and feedback port238. Receivers212and214receive data packets transmitted from sender210by way of media in ports232and236, respectively. Media in ports232and236refer to logical port designations and are addressable by sender210. In embodiments of the invention, receiver212,214can include any number of media in ports232,236. In some embodiments, receiver212,214can include ports associated with various types of protocols, applications, media types, and the like. Each receiver212and214have corresponding IP addresses, which may be static or dynamically assigned, and the combination of a receiver's IP address and a port number is referred to as a socket identification. Thus, as mentioned above, a communication session can be identified by a pair of socket identifiers—a source socket identifier (e.g., an IP address and media out port number associated with sender210) and a destination socket identifier (e.g., an IP address and media in port number associated with receiver212).

AsFIG. 2further illustrates, receivers212and214each include a feedback port234and238, respectively. Receivers212and214can transmit feedback messages to sender210by way of feedback ports234and238. In this manner, the feedback communications described herein can be borne “out-of-band” with respect to the streaming content. Thus, feedback systems and methods such as those described herein can be added to existing data packet streamers, servers, and the like without affecting the functionality of the data packet streaming technology. Additionally, feedback can be generated, transmitted, received, and processed without interruption in the content stream.

Turning now toFIG. 3, an exemplary receiver operating environment for implementing embodiments of the invention is illustrated. As shown inFIG. 3, receiver300includes applications310,312, and314; media in ports316,318, and320; a user interface (UI)322; a user-experience manager324; and a feedback port326. As discussed above with reference toFIG. 2, receiver300can include any number of types of entities such as, for example, a client module on a computing device, a computing device, a wireless communications device, a client module on a wireless communications device, and the like. Receiver300is merely an example of one suitable receiver and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention. Neither should receiver300be interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein.

According to various embodiments of the invention, applications310,312, and314can include applications, services, programs, program modules, scripts, application programming interfaces (APIs), drivers, hardware accelerators, and the like. In embodiments, applications310,312, and314process data packets received by way of media in ports316,318, and320, respectively. Applications310,312, and314can work with UI322to present media to a user. Accordingly, applications310,312, and314can communicate with, or include, codecs, filters, digital rights management modules, descramblers, and the like. Compressed or encoded media can be received via media in ports316,318, and320and decompressed, decoded, processed, analyzed, rendered, displayed, stored, and the like by applications310,312, and314and UI322. In various embodiments, an application310,312, or314can be configured to facilitate a service such as VoIP, online gaming, video streaming, instant messaging, and the like. Other modules and components not illustrated inFIG. 3can also be included in receiver300for processing content.

As illustrated inFIG. 3, receiver300includes a user-experience manager324that organizes and manages the functionalities, services, and operations corresponding to applications310,312, and314. User-experience manager324can be a software module, program, application, API, or the like and can include interfaces for providing a user with access to configuration options, service selections, and the like. In embodiments, user-experience manager324includes monitors for monitoring event stacks, communications, pings, and the like associated with media in ports316,318, and320. In this manner, user-experience manager324can keep track of the type, quality, amount, and rate of incoming data packets from sender210.

According to various embodiments of the invention, user-experience manager324includes modules and components that allow monitoring of applications310,312, and314and UI322so that user-experience manager324can determine which services the user is most likely using, or paying direct attention to, at any given time, thereby facilitating enhancement of the user's overall experience. For example, as illustrated inFIG. 3, user-experience manager324includes a focus detection module328, an allocation module330, and a feedback message module332. User-experience manager324is merely an example of one suitable management module and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention. Neither should user-experience manager324be interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein.

In embodiments of the invention, user-experience manager324keeps track of which applications310,312,314are active and which applications have focus. An application has focus when it is the application corresponding to the media, content, service, or function with which the user is currently interacting, viewing, experiencing, and the like. In one embodiment, user-experience manager324identifies active applications by using an API, method call, or other type of process to discover that an application310,312,314is currently running on receiver300. In an embodiment, user-experience manager324determines that an application has focus by referencing applications310,312, and314by way of an API or other similar communication conduit. In another embodiment, user-experience manager324determines whether an application has focus by referencing UI322.

According to various embodiments of the invention, user-experience manager324can communicate with UI322to determine which applications310,312, and314have focus and which do not. It should be understood that, in some embodiments, more than one application can have focus at a given time. In embodiments, an application has focus if the application corresponds to the immediate user experience. One way to identify which applications correspond to the immediate user experience is to reference the UI322to determine what is being presented on the display device associated with receiver300.

In various embodiments, receiver300includes an operating system and/or other system software that enables a windowing environment to be presented to a user by way of UI322. Turning briefly toFIGS. 5A and 5B, there is illustrated an exemplary display500that includes a number of application windows, labeled “1,” “2,” and “3.” Display500is oriented in an X-Y plane of a 3-dimensional space. That is, the horizontal direction inFIG. 1may be represented by an X-axis and the vertical direction may be represented by a Y-axis. Accordingly, a positive Z-axis would be directed orthogonally to the X- and Y-axes. It will be understood by those having knowledge in the art that application windows can be arranged on a display such that some windows overlap others. Generally, the window that is “on top” is the window corresponding to the application that has focus—this way a user can interact with the application having focus without the experience being obscured by other application windows. As used herein, the term “z-value” refers to the position of an application window along the Z-axis.

Thus, as illustrated inFIG. 5A, application window “1” has a highest z-value510, and since application window “2” is “behind” application window “1,” application window “2” has a lower z-value512than the z-value510of application window “1.” In embodiments, application window “3” may have a z-value514that is equal to, higher than, or lower than the z-value510of application window “1.” This may occur when a user is currently interacting with more than one application. Additionally, in various embodiments, z-values can be represented by scaled numerical values assigned based on a graphical representation of the display space. In other embodiments, z-values can be represented by ranks such that each z-value indicates the position of an application window along the Z-axis with respect to the positions of other application windows on a display. Thus, for example, inFIG. 5A, application window “1” might have a z-value of 1, whereas application window “2” might have a z-value of 2. In other embodiments, other identification schemes can be used for assigning and operating on z-values corresponding to application windows rendered on a display associated with receivers.

As illustrated inFIG. 5A, application window “1” corresponds to an application that has focus. Additionally, in some embodiments, application window “3” may also correspond to an application that has focus. In response to an input from a user, an instruction from a program, or other device or entity, focus can be changed from one application window to another. Thus, as illustrated inFIG. 5B, application window “1” no longer has focus. Focus has been shifted to application window “2.” Additionally, application window “3” is more clearly not in focus inFIG. 5Bas it appears to be partially obscured by application windows “1” and “2.” This change in focus can be affected in response to, for example, a user clicking on application window “2.” As users multitask and switch between different application windows, the corresponding demands upon the applications shift, often many times within a short period of time. Thus, inFIG. 5B, application window “2” has the highest z-value510, application window “1” has the next highest z-value512, and application window “3” has the lowest z-value516. By determining z-values associated with application windows, and thus applications, the user-experience manager324, illustrated inFIG. 3, can determine which application is in focus at any given time, and can thereby allocate bandwidth capabilities appropriately so that more bandwidth is dedicated to applications having focus, thereby enhancing the user's overall experience. Embodiments of the invention allow for dynamic assessment of bandwidth usage and requirement amounts, and dynamic provisioning of bandwidth to applications based on focus (e.g., based on what the user is experiencing).

Returning toFIG. 3, as illustrated, user-experience manager324includes focus detection module328, which can identify active applications, and can determine which of the active applications have focus at a given instant of time. In embodiments, focus detection module328provides information regarding which applications are active and which applications have focus to allocation module330. According to embodiments of the invention, allocation module330determines current bandwidth usage amounts associated with applications310,312, and314. In embodiments, allocation module330references applications310,312, and314using an API or other conduit to determine bandwidth requirement amounts associated with the applications310,312, and314. In embodiments, bandwidth requirement amounts can include packet transmission rates, bandwidth measurements, and the like that are necessary for a minimal level of functionality. In other embodiments, bandwidth requirement amounts can refer to optimum bandwidths for high-quality experiences. In further embodiments, bandwidth requirement amounts can refer to ranges within which bandwidths provide for acceptable, good, or exceptional functionality. Other particularities and nuances can be included within bandwidth requirement amounts, depending on the associated services and technology, and all are considered to be within the ambit of this disclosure.

Allocation module330also can determine bandwidth usage amounts corresponding to communication sessions and/or associated applications310,312, and314. In embodiments, allocation module330can reference applications310,312, and314to determine bandwidth usage amounts. In other embodiments, allocation module330can reference monitors of media in ports316,318, and320to obtain bandwidth usage amounts. In embodiments, bandwidth usage amounts can include measurements of packet receipt rates, packet size, and the like, and can include discrete measurements or ranges of measurements. By comparing bandwidth usage amounts and bandwidth requirement amounts associated with active applications having focus to similar attributes associated with active applications that do not have focus, allocation module330can determine optimum bandwidth adjustment amounts for enhancement of the user's experience. That is, if application310is active and has focus and requires a large amount of bandwidth for quality functionality, allocation module330might determine that the corresponding bandwidth should be increased, while bandwidths associated with applications that do not have focus, or that have lower requirements such as, for example, applications312and314may be reduced. In this manner, a receiving device300can better take advantage of the bandwidth capabilities inherent to the device, the networks, the content providers, and the like by provisioning bandwidth between communication sessions based on the user's experience.

As further illustrated inFIG. 3, user-experience manager324includes feedback message module332. Feedback message module332generates feedback messages that can be provided to a sender to request adjustments to bandwidth based on decisions made in the allocation module330. Thus, for example, focus detection module328might determine that an application312that previously did not have focus has just been given focus. Accordingly, allocation module330can determine a bandwidth increase appropriate for application312and, potentially, bandwidth decrease amounts appropriate for applications310and314. The bandwidth adjustment amounts and an identification of the corresponding communication sessions are communicated to feedback message module332, which generates a feedback message corresponding to each session to be transmitted via feedback port326to the associated sender.

Turning briefly toFIG. 4A, a schematic block diagram is shown, which depicts an illustrative implementation of an embodiment of the invention. A sender410transmits a plurality of data packets422to a receiver412. Although not illustrated inFIG. 4A, a network or a number of networks can be disposed between sender410and receiver412and any number of other components, entities, devices, or the like can be included according to various embodiments of the invention. The illustrative implementation depicted inFIG. 4Ais merely an example of one suitable implementation of the invention and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention. Neither should the illustrative implementation depicted inFIG. 4Abe interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein.

As illustrated inFIG. 4A, the communication session characterized by the sending of data packets422to receiver412can be identified by socket identifications. Sender410includes a first socket414, SOCKET-1, which identifies an IP address and port number associated with sender410and corresponding to the transmission of data packets422to receiver412. Similarly, receiver412includes a second socket418, SOCKET-2, which identifies an IP address and port number associated with receiver412and corresponding to the receipt of data packets422from sender410. Thus, the data session can be identified by the first and second sockets414,418(i.e., SOCKET-1and SOCKET-2).

Receiver412can include software modules, clients, or the like that monitor the communication session identified by SOCKET-1and SOCKET-2. If there is some decrease in quality associated with the stream of data packets422or if there is a change in the application that has focus on receiver412, as discussed above with reference toFIG. 3, receiver412can generate a feedback message424and communicate the feedback message424to sender410. In various embodiments of the invention, the feedback message424can include an instruction or request to adjust the bandwidth, rate of packet transmission, packet size, packet format, and the like. The feedback message424includes an identification of the communication session to which the feedback corresponds, so that sender410can apply the requested adjustment to the correct data packet stream.

As depicted inFIG. 4A, sender410includes a third socket416, SOCKET-3. SOCKET-3416can correspond to a generic, or “well-known,” port number that is established for the purpose of receiving feedback messages from receivers such as receiver412. Similarly, receiver412can include a fourth socket420, SOCKET-4, through which receiver412transmits feedback messages424to sender410. In various embodiments, feedback message424can also include identifications associated with the third and fourth sockets416,420. For example, as illustrated inFIG. 4B, an exemplary feedback message424is depicted in accordance with embodiments of the invention.

As shown inFIG. 4B, feedback message424may include an IP header426, a UDP header428, and a payload430. In various embodiments, IP header426can be configured according to any number of versions of IP such as, for example, IP version 4 (IPv4) and IP version 6 (IPv6). Similarly, UDP header428can, in other embodiments, be a header associated with some connectionless protocol other than UDP. In various embodiments, feedback message424can also include extensions, tails, modifications, and the like. Additional headers can also be included in various embodiments of the invention. Feedback message424is an example of one suitable feedback message format and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention. Neither should feedback message424be interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein.

As illustrated inFIG. 4B, IP header426includes a source IP address432and a destination IP address434. For example, according to embodiments of the invention, the feedback message424depicted inFIG. 4Aincludes a source IP address432associated with receiver412, because receiver412is the source of feedback message424. IP header426also includes an IP address434associated with sender410because sender410is the destination of feedback message424. Similarly, the UDP header428includes a source port number436, which is associated with the fourth socket420, SOCKET-4. UDP header428also includes a destination port number438, which is associated with the third socket416, SOCKET-3. It should be evident then, that in some embodiments, feedback message424includes socket identifications corresponding to SOCKET-3and SOCKET-4in header fields. This information may also be referred to as addressing information because it includes the addresses necessary for routing the feedback message424.

As further illustrated inFIG. 4B, feedback message424includes a payload430. Payload430includes an application header440, which identifies an application associated with receiver412that is involved in or corresponds to the communication session identified, for example, by a pair of socket identifications414,418. In embodiments, application header440can include a code, a name, or some other indication related to the corresponding application. Payload430also includes a session identifier442. Session identifier442can be used by a sender, such as sender410illustrated inFIG. 4A, to identify the session to which the feedback message corresponds. As illustrated, session identifier442includes a first socket identification446and a second socket identification448(e.g., SOCKET-1and SOCKET-2). Together, the two socket identifiers446and448identify the corresponding communication session, which, as illustrated inFIG. 4A, comprises the transmission of data packets422from sender410to receiver412via SOCKET-1and SOCKET-2. In various embodiments of the invention, other codes, numbers, addressing information, or the like can be included in payload430for identifying communications sessions and other facts.

Payload430further includes an instruction444(e.g., request) for an adjustment of bandwidth corresponding to the session identified by session identifier442. The instruction can be generated in any number of types of code, pseudocode, Unicode, and the like and include any number of instructions related to adjustment of bandwidth. In one example, instruction444can include data that is assigned to a variable associated with the corresponding communication session, thereby adjusting an attribute thereof relating to packet transmission rate, bandwidth, packet size, choice of codec, or the like. Additional information, instructions, and/or requests can be included in extensions, headers, tails, and the like.

To recapitulate, we have described systems for using feedback messages to manage bandwidth associated with packet streaming sessions. Turning toFIG. 6, a flow diagram is provided, showing an illustrative method of managing bandwidth corresponding to one or more communication sessions associated with a receiver on a computing device. At a first illustrative step, step610, a user-experience manager in a receiver references a plurality of active applications. Each application can correspond to one or more communication sessions. Data sessions, as explained above, can be characterized by the transmission of data packets from a sender to the receiver.

As further illustrated inFIG. 6, the user-experience manager determines whether each of the active applications has focus. More particularly, in one embodiment, as shown at step612, the user-experience manager determines that a first application has focus. The first application can correspond to a first communication session with a first sender. As shown at step614, the user-experience manager determines a bandwidth requirement amount associated with the first session. In various embodiments, the bandwidth requirement amount can include rates of packet transmission, packet size, and the like corresponding to a minimal user experience. In other embodiments, bandwidth requirement amounts can correspond to higher-quality user experiences.

As illustrated at step616, the user-experience manager determines a bandwidth usage amount associated with the first session and compares the amount with the bandwidth requirement amount. If, as shown at step618, it is determined that the bandwidth usage amount is less than the bandwidth requirement amount, the user-experience manager can reference other active applications to determine corresponding bandwidth usage and requirement amounts and to determine whether the applications have focus. Based on all of the collected data, the user-experience manager can make optimizing decisions for allocating bandwidth capabilities associated with the receiver between the various communication sessions associated with the applications. To realize the goals of the decisions made, the user-experience manager can generate a feedback message for providing feedback, requests, and instructions for bandwidth adjustments to the sender. At a final illustrative step620, the receiver can provide the feedback to the first sender to request an increase in the bandwidth of the first communication session (and possibly decreases in bandwidths associated with other sessions).

Turning now toFIG. 7, a flow diagram showing an illustrative method of dynamically managing a plurality of communication sessions associated with a receiver is illustrated. At a first illustrative step710, a user-experience manager associated with a receiver identifies a plurality of active applications. Each active application can be associated with a communication session. For example, in an embodiment, a first application can be associated with a first communication session with a first sender, and a second application can be associated with a second communication session with a second sender. As shown at step712, the user-experience manager determines that a first one of the plurality of active applications has focus. Additionally, the user-experience manager determines that a second application does not have focus, as shown at step714.

With reference to step716ofFIG. 7, the user-experience manager determines a first bandwidth usage amount corresponding to the first session and, at step718, the user-experience manager determines a second bandwidth usage amount corresponding to the second communication session. A bandwidth requirement amount corresponding to the first session is determined at step720. In various embodiments, bandwidth requirement amounts corresponding to any and/or all of the other communication sessions can also be determined. As shown at step722, the user-experience manager determines that the bandwidth requirement amount for the first session is greater than the bandwidth usage amount associated with the first session. Then, based on information about the various applications and communication sessions, the user-experience manager computes an appropriate bandwidth adjustment amount (e.g., an increase) corresponding to the first session, as shown at step724. In a final illustrative step726, the receiver communicates a feedback message to the first sender. The feedback message can include an identification of the first communication session and an instruction. For example, in an embodiment, the feedback message includes a request to adjust the first bandwidth according to the appropriate bandwidth adjustment amount computed by the user-experience manager.

Many different arrangements of the various components depicted, as well as components not shown, are possible without departing from the spirit and scope of the invention. For example, in some embodiments, user-experience managers may be configured to wait for a predetermined amount of time before communicating a feedback message in response to a focus status change in relation to an application. In this way, feedback messages will be less likely to be communicated based on accidental or very temporary shifts in focus. Furthermore, embodiments of the invention have been described with the intent to be illustrative rather than restrictive. It will be understood that certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations and are contemplated within the scope of the claims. Not all steps listed in the various figures need be carried out in the specific order described, unless otherwise specified.