U.S. patent application number 17/507310 was filed with the patent office on 2022-04-28 for session reconnects and dynamic resource allocation.
The applicant listed for this patent is Meta Platforms, Inc.. Invention is credited to Qi Ding, Francisco Javier Merino Guardiola, Naizhi Li, Carlos Lopez Menendez, Yangpeng Ou, Qunshu Zhang, Xiaoxing Zhu.
Application Number | 20220131943 17/507310 |
Document ID | / |
Family ID | 1000005971667 |
Filed Date | 2022-04-28 |
![](/patent/app/20220131943/US20220131943A1-20220428-D00000.png)
![](/patent/app/20220131943/US20220131943A1-20220428-D00001.png)
![](/patent/app/20220131943/US20220131943A1-20220428-D00002.png)
![](/patent/app/20220131943/US20220131943A1-20220428-D00003.png)
![](/patent/app/20220131943/US20220131943A1-20220428-D00004.png)
![](/patent/app/20220131943/US20220131943A1-20220428-D00005.png)
![](/patent/app/20220131943/US20220131943A1-20220428-D00006.png)
United States Patent
Application |
20220131943 |
Kind Code |
A1 |
Zhang; Qunshu ; et
al. |
April 28, 2022 |
SESSION RECONNECTS AND DYNAMIC RESOURCE ALLOCATION
Abstract
The disclosed computer-implemented method may include detecting,
by a cloud-based software distribution host providing cloud-based
access to an application to a client device, a pause in a user
session of the application and in response to the detection, saving
a user session state of the user session. The method may also
include determining, based on one or more session characteristics
relating to the user session, a session preservation time for
preserving the user session state. The session preservation time
may correspond to a predicted time for keeping the user session
alive. The method may further include storing the saved user
session state in a session state buffer for at least the determined
session preservation time, and removing the user session state from
the session state buffer after the session preservation time
elapses. Various other methods, systems, and computer-readable
media are also disclosed.
Inventors: |
Zhang; Qunshu; (Sammamish,
WA) ; Zhu; Xiaoxing; (Bellevue, WA) ; Ou;
Yangpeng; (Redmond, WA) ; Ding; Qi; (Seattle,
WA) ; Guardiola; Francisco Javier Merino; (Madrid,
ES) ; Menendez; Carlos Lopez; (Madrid, ES) ;
Li; Naizhi; (Redmond, WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Meta Platforms, Inc. |
Menlo Park |
CA |
US |
|
|
Family ID: |
1000005971667 |
Appl. No.: |
17/507310 |
Filed: |
October 21, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
63194821 |
May 28, 2021 |
|
|
|
63105320 |
Oct 25, 2020 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 67/42 20130101;
H04L 67/141 20130101; H04L 67/306 20130101; H04L 67/145
20130101 |
International
Class: |
H04L 29/08 20060101
H04L029/08; H04L 29/06 20060101 H04L029/06 |
Claims
1. A computer-implemented method comprising: detecting, by a
cloud-based software distribution host providing cloud-based access
to an application to a client device, a pause in a user session of
the application; in response to the detection, saving a user
session state of the user session, wherein the user session state
includes a memory state of the application corresponding to a
user's activity during the user session; determining, based on one
or more session characteristics relating to the user session, a
session preservation time for preserving the user session state,
wherein the session preservation time corresponds to a predicted
time for keeping the user session alive; storing the saved user
session state in a session state buffer for at least the determined
session preservation time; and removing the user session state from
the session state buffer after the session preservation time
elapses.
2. The method of claim 1, further comprising: detecting, before the
session preservation time elapses, a reconnection of the user
session; and loading the user session state from the session state
buffer to restore the user session.
3. The method of claim 2, further comprising tracking a
reconnection time of the user session, wherein the one or more
session characteristics includes an average reconnection time for
the user and the session preservation time is further based on the
average reconnection time.
4. The method of claim 1, wherein the one or more session
characteristics includes at least one of an application
characteristic of the application, a popularity of the application,
or a return rate of users of the application.
5. The method of claim 1, wherein the one or more session
characteristics includes at least one of an application usage
pattern of a user or a return rate of the user.
6. The method of claim 1, wherein the pause corresponds to at least
one of the client device disconnecting from the cloud-based
software distribution host or the user minimizing the
application.
7. The method of claim 1, wherein the application comprises a video
game and the user session state corresponds to a progress of the
user in the video game.
8. A system comprising: at least one physical processor; and
physical memory comprising computer-executable instructions that,
when executed by the physical processor, cause the physical
processor to: detect, by a cloud-based software distribution host
providing cloud-based access to an application to a client device,
a pause in a user session of the application; in response to the
detection, save a user session state of the user session, wherein
the user session state includes a memory state of the application
corresponding to a user's activity during the user session;
determine, based on one or more session characteristics relating to
the user session, a session preservation time for preserving the
user session state, wherein the session preservation time
corresponds to a predicted time for keeping the user session alive;
store the saved user session state in a session state buffer for at
least the determined session preservation time; and remove the user
session state from the session state buffer after the session
preservation time elapses.
9. The system of claim 8, wherein the instructions further comprise
instructions for: detecting, before the session preservation time
elapses, a reconnection of the user session; and loading the user
session state from the session state buffer to restore the user
session.
10. The system of claim 9, wherein the instructions further
comprise instructions for tracking a reconnection time of the user
session, wherein the one or more session characteristics includes
an average reconnection time for the user and the session
preservation time is further based on the average reconnection
time.
11. The system of claim 8, wherein the one or more session
characteristics includes at least one of an application
characteristic of the application, a popularity of the application,
or a return rate of users of the application.
12. The system of claim 8, wherein the one or more session
characteristics includes at least one of an application usage
pattern of a user, or a return rate of the user.
13. The system of claim 8, wherein the pause corresponds to at
least one of the client device disconnecting from the cloud-based
software distribution host, or the user minimizing the
application.
14. A non-transitory computer-readable medium comprising one or
more computer-executable instructions that, when executed by at
least one processor of a computing device, cause the computing
device to: detect, by a cloud-based software distribution host
providing cloud-based access to an application to a client device,
a pause in a user session of the application; in response to the
detection, save a user session state of the user session, wherein
the user session state includes a memory state of the application
corresponding to a user's activity during the user session;
determine, based on one or more session characteristics relating to
the user session, a session preservation time for preserving the
user session state, wherein the session preservation time
corresponds to a predicted time for keeping the user session alive;
store the saved user session state in a session state buffer for at
least the determined session preservation time; and remove the user
session state from the session state buffer after the session
preservation time elapses.
15. The non-transitory computer-readable medium of claim 14,
wherein the instructions further comprise instructions for:
detecting, before the session preservation time elapses, a
reconnection of the user session; and loading the user session
state from the session state buffer to restore the user
session.
16. The non-transitory computer-readable medium of claim 15,
wherein the instructions further comprise instructions for tracking
a reconnection time of the user session, wherein the one or more
session characteristics includes an average reconnection time for
the user and the session preservation time is further based on the
average reconnection time.
17. The non-transitory computer-readable medium of claim 14,
wherein the one or more session characteristics includes at least
one of an application characteristic of the application, a
popularity of the application, or a return rate of users of the
application.
18. The non-transitory computer-readable medium of claim 14,
wherein the one or more session characteristics includes at least
one of an application usage pattern of a user, or a return rate of
the user.
19. The non-transitory computer-readable medium of claim 14,
wherein the pause corresponds to at least one of the client device
disconnecting from the cloud-based software distribution host, or
the user minimizing the application.
20. The non-transitory computer-readable medium of claim 14,
wherein the application comprises a video game and the user session
state corresponds to a progress of the user in the video game.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application claims the benefit of U.S. Provisional
Application No. 63/105,320, filed 25 Oct. 2020, and U.S.
Provisional Application No. 63/194,821, filed 28 May 2021, the
disclosures of each of which are incorporated, in their entirety,
by this reference. Co-pending U.S. application Ser. No. 17/506,640,
filed 20 Oct. 2021, is incorporated, in its entirety, by this
reference.
BRIEF DESCRIPTION OF THE DRAWINGS
[0002] The accompanying drawings illustrate a number of exemplary
embodiments and are a part of the specification. Together with the
following description, these drawings demonstrate and explain
various principles of the present disclosure.
[0003] FIG. 1 is a flow diagram of an exemplary method for managing
session reconnects and dynamic resource allocation for a cloud
hosting platform.
[0004] FIG. 2 is a block diagram of an exemplary system for
managing session reconnects and dynamic resource allocation for a
cloud hosting platform.
[0005] FIG. 3 is a block diagram of an exemplary network for
managing session reconnects and dynamic resource allocation for a
cloud hosting platform.
[0006] FIG. 4 is a block diagram of an exemplary architecture for a
cloud hosting platform.
[0007] FIG. 5 is a diagram of a session reconnect.
[0008] FIG. 6 is a diagram of an exemplary buffer for managing
session reconnects and dynamic resource allocation for a cloud
hosting platform.
[0009] Throughout the drawings, identical reference characters and
descriptions indicate similar, but not necessarily identical,
elements. While the exemplary embodiments described herein are
susceptible to various modifications and alternative forms,
specific embodiments have been shown by way of example in the
drawings and will be described in detail herein. However, the
exemplary embodiments described herein are not intended to be
limited to the particular forms disclosed. Rather, the present
disclosure covers all modifications, equivalents, and alternatives
falling within the scope of the appended claims.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
[0010] A cloud platform may provide, to remote devices, cloud-based
access to computing resources (e.g., data, applications,
processing, etc.) available on the cloud platform, such as
applications. A client device may connect to the cloud platform and
run an application, hosted by the cloud platform, as if running
natively on the client device. The server hosting environment of
the cloud platform may maintain a user session data for the client
device's application session to provide the native application
experience. When the client device ends the session, the host
server may no longer need to maintain the user session data and may
therefore delete the user session data.
[0011] When users run applications natively on their own client
device, the users may pause application sessions and later return.
For example, a user may turn off his or her device, thereby pausing
an application session of an active application running on the
device. When the user turns on the device again, the application
session for the active application may be resumed. The cloud
platform may provide similar functionality of maintaining a user
session by saving the user session data as a user session state
when the client device pauses an application session. When the
client device reconnects to the application session, the cloud
platform may restore the user's session by retrieving the
corresponding user session state.
[0012] However, storing the user session state indefinitely may be
resource prohibitive. As application sessions increase, whether
from the user using other applications or other users using
applications, a number of user session states may increase such
that storing all the user session states may quickly exhaust
available memory. Although the user session states may be managed
by deleting stale data, such schemes may cause a user's session
state to be deleted before the user reconnects. The user's session
may not be restored to the detriment of the user's experience.
[0013] The present disclosure is generally directed to managing
session reconnects and dynamic resource allocation. As will be
explained in greater detail below, embodiments of the present
disclosure may detect a pause in a user session, determine a
session preservation time for the user session, and storing a user
session state of the user session for at least the session
preservation time. By determining the session preservation time
based on predicting a time for keeping the user session alive, the
systems and methods described herein may provide a better user
experience in reconnecting to sessions. The systems and methods
described herein may improve the functioning of a computer itself
by more efficiently storing and maintaining session state data. In
addition, the systems and methods described herein may improve the
field of state memory management by better predicting keep-alive
times.
[0014] Features from any of the embodiments described herein may be
used in combination with one another in accordance with the general
principles described herein. These and other embodiments, features,
and advantages will be more fully understood upon reading the
following detailed description in conjunction with the accompanying
drawings and claims.
[0015] The following will provide, with reference to FIGS. 1-6,
detailed descriptions of systems and methods for managing session
reconnects and dynamic resource allocation. Detailed descriptions
of an exemplary method for managing session reconnects and dynamic
resource allocation are provided with FIG. 1. Detailed descriptions
of an exemplary computing system are provided with FIG. 2. Detailed
descriptions of an exemplary network system are provided with FIG.
3. Detailed descriptions of an exemplary cloud-based software
distribution host are provided with FIG. 4. Detailed descriptions
of an example session reconnect are provided with FIG. 5. Detailed
descriptions of an example buffer for maintaining user session
states are provided with FIG. 6.
[0016] FIG. 1 is a flow diagram of an exemplary
computer-implemented method 100 for managing session reconnects and
dynamic resource allocation. The steps shown in FIG. 1 may be
performed by any suitable computer-executable code and/or computing
system, including the system(s) illustrated in FIGS. 2 and/or 3. In
one example, each of the steps shown in FIG. 1 may represent an
algorithm whose structure includes and/or is represented by
multiple sub-steps, examples of which will be provided in greater
detail below.
[0017] As illustrated in FIG. 1, at step 110 one or more of the
systems described herein may detect, by a cloud-based software
distribution host providing cloud-based access to an application to
a client device, a pause in a user session of the application. For
example, a session module 204 depicted in FIG. 2 may detect a pause
in a user session 222.
[0018] In some embodiments, the term "user session" or "session"
may refer to a temporary and interactive information interchange
between communicating devices, such as a session of activity and/or
interactions of a client referencing a resource that may be tracked
by the resource's host. For example, a website host may track a
user's activity during a session with a website provided by the
website host. A user session may be used by a host to maintain user
specific state, persistent objects, authenticated user identities,
etc., and may further facilitate communication between the client
and host by remembering previous interactions/communications. The
state of the user session may be maintained in a memory during the
session and as such, may be stored to a storage device and later
retrieved. Thus, the user session may be paused, the session state
stored, and the user session may be restored by retrieving the
stored session state. For example, as will be discussed further
below, the systems and methods described herein may manage user
session states.
[0019] Various systems described herein may perform step 110. FIG.
2 is a block diagram of an example system 200 for managing session
reconnects and dynamic resource allocation. As illustrated in this
figure, example system 200 may include one or more modules 202 for
performing one or more tasks. As will be explained in greater
detail herein, modules 202 may include a session module 204, a
state module 206, a preservation module 208, and a buffer module
210. Although illustrated as separate elements, one or more of
modules 202 in FIG. 2 may represent portions of a single module or
application.
[0020] In certain embodiments, one or more of modules 202 in FIG. 2
may represent one or more software applications or programs that,
when executed by a computing device, may cause the computing device
to perform one or more tasks. For example, and as will be described
in greater detail below, one or more of modules 202 may represent
modules stored and configured to run on one or more computing
devices, such as the devices illustrated in FIG. 3 (e.g., computing
device 302 and/or server 306). One or more of modules 202 in FIG. 2
may also represent all or portions of one or more special-purpose
computers configured to perform one or more tasks.
[0021] As illustrated in FIG. 2, example system 200 may also
include one or more memory devices, such as memory 240. Memory 240
generally represents any type or form of volatile or non-volatile
storage device or medium capable of storing data and/or
computer-readable instructions. In one example, memory 240 may
store, load, and/or maintain one or more of modules 202. Examples
of memory 240 include, without limitation, Random Access Memory
(RAM), Read Only Memory (ROM), flash memory, Hard Disk Drives
(HDDs), Solid-State Drives (SSDs), optical disk drives, caches,
variations or combinations of one or more of the same, and/or any
other suitable storage memory.
[0022] As illustrated in FIG. 2, example system 200 may also
include one or more physical processors, such as physical processor
230. Physical processor 230 generally represents any type or form
of hardware-implemented processing unit capable of interpreting
and/or executing computer-readable instructions. In one example,
physical processor 230 may access and/or modify one or more of
modules 202 stored in memory 240. Additionally or alternatively,
physical processor 230 may execute one or more of modules 202 to
facilitate maintain the mapping system. Examples of physical
processor 230 include, without limitation, microprocessors,
microcontrollers, Central Processing Units (CPUs),
Field-Programmable Gate Arrays (FPGAs) that implement softcore
processors, Application-Specific Integrated Circuits (ASICs),
portions of one or more of the same, variations or combinations of
one or more of the same, and/or any other suitable physical
processor.
[0023] As illustrated in FIG. 2, example system 200 may also
include one or more additional elements 220, such as user session
222, user session state 224, session preservation time 226, and
session state buffer 228. User session 222, user session state 224,
session preservation time 226, and/or session state buffer 228 may
be stored on a local storage device, such as memory 240, or may be
accessed remotely. User session 222 may represent a memory state
corresponding to a user's current application session, as will be
explained further below. User session state 224 may represent data
corresponding to the user session 222. Session preservation time
226 may represent a time for keeping user session state 224.
Session state buffer 228 may represent a buffer for storing session
states such as user session state 224, as will be explained further
below.
[0024] Example system 200 in FIG. 2 may be implemented in a variety
of ways. For example, all or a portion of example system 200 may
represent portions of example network environment 300 in FIG.
3.
[0025] FIG. 3 illustrates an exemplary network environment 300
implementing aspects of the present disclosure. The network
environment 300 includes computing device 302, a network 304, and
server 306. Computing device 302 may be a client device or user
device, such as a smartphone, a desktop computer, laptop computer,
tablet device, smartphone, or other computing device. Computing
device 302 may include a physical processor 230, which may be one
or more processors, and memory 240, which may store data such as
one or more of additional elements 220.
[0026] Server 306 may represent or include one or more servers
capable of hosting cloud-based software distribution platform.
Server 306 may provide cloud-based access to applications to
computing device 302. Server 306 may include a physical processor
230, which may include one or more processors, memory 240, which
may store modules 202, and one or more of additional elements
220.
[0027] Computing device 302 may be communicatively coupled to
server 306 through network 304. Network 304 may represent any type
or form of communication network, such as the Internet, and may
comprise one or more physical connections, such as LAN, and/or
wireless connections, such as WAN.
[0028] As described herein, server 306 may correspond to a
cloud-based software distribution host. In some embodiments, the
cloud-based software distribution host may host software
applications for cloud-based access. Software applications,
particularly games, are often developed for a specific OS and
require porting to run on other OSes. However, the cloud-based
software distribution host described herein (also referred to as
the cloud-based software distribution platform herein) may provide
cloud-based access to games designed for a particular OS on a
device running an otherwise incompatible OS for the games. For
example, the platform may host a desktop game and allow a mobile
device (or other device running an OS that is not supported by the
game) to interact with an instance of the desktop game as if
running on the mobile device. Similarly, the platform may host a
mobile game and allow a desktop computer (or other device running
an OS that is not supported by the game) to interact with an
instance of the mobile game as if running on the desktop computer.
Although the examples herein refer to games as well as OS
incompatibility, in other examples the software applications may
correspond to any software application that may not be supported or
is otherwise incompatible with another computing device, including
but not limited to OS, hardware, etc.
[0029] FIG. 4 illustrates an exemplary cloud-based software
distribution platform 400. The platform 400 may include a host 406,
a network 404 (which may correspond to network 304), and computing
devices 402 and 403. Host 406, which may correspond to server 306,
may include containers 440 and 442, which may respectively include
a virtual machine 430 and a virtual machine 432.
[0030] In some embodiments, the term "virtualization environment"
may refer to an isolated application environment that may
virtualize at least some aspects of the application environment
such that an application may interface with the virtualized aspects
as if running on the application's native environment. Examples of
virtualization environments include, without limitation, containers
and virtual machines ("VM"). In some embodiments, the term
"container" may refer to an isolated application environment that
virtualizes at least an operating system ("OS") of the base host
machine by sharing a system or OS kernel with the host machine. For
example, if the base host machine runs Windows (or other desktop
OS), the container may also run Windows (or other desktop OS) by
sharing the OS kernel such that the container may not require a
complete set of OS binaries and libraries. In some embodiments, the
term "virtual machine" may refer to an isolated application
environment that virtualizes hardware as well as an OS. Because a
VM may virtualize hardware, an OS for the VM may not be restricted
by the base host machine OS. For example, even if the base host
machine is running Windows (or another desktop OS), a VM on the
base host machine may be configured to run Android (or other mobile
OS) by emulating mobile device hardware. In other examples, other
combinations of OSes may be used.
[0031] VM 430 may run an application 420 and VM 432 may run an
application 422. Host 406 may utilize nested virtualization
environments (e.g., VM 430 running in container 440 and VM 432
running in container 442) to more efficiently manage virtualization
environments. For instance, as a number of VMs are initiated and/or
closed the nested virtualization may facilitate management of
virtualization environments for various types of VMs as well as
more efficiently scale the number of VMs running concurrently.
Certain aspects which may be global across certain VMs may be
better managed via containers.
[0032] Computing device 402, which may correspond to an instance of
computing device 302, may access application 420 via network 404.
Computing device 403, which may correspond to another instance of
computing device 302, may access application 422 via network 404.
As shown in FIG. 4, because application 420 and application 422 are
actually running on host 406, host 406 may maintain individual
sessions (e.g., user session 222) for each of application 420 with
computing device 402 and application 422 with computing device
403.
[0033] Although FIG. 4 illustrates a virtualization environment
with one nested level (e.g., VM 430 running in container 440 or VM
432 running in container 442), in other embodiments, the
virtualization environment may include additional levels of
nesting. For example, application 420 may run in another VM or
container running in VM 430. Moreover, although FIG. 4 illustrates
a single VM per container, in other embodiments there may be more
than one nested virtualization environment per base virtualization
environment.
[0034] Returning to FIG. 1, the systems described herein may
perform step 110 in a variety of ways. In one example, session
module 204 may establish and manage user session 222 that may be
between a client device (e.g., computing device 302, computing
device 402 and/or computing device 403) and a host (e.g., server
306 and/or host 406) for running an application (e.g., application
420 and/or application 422, respectively). FIG. 5 illustrates
another exemplary session.
[0035] FIG. 5 illustrates an example timeline of a session 500.
FIG. 5 may include a host 506 (which may correspond to server 306
and/or host 406), an application 520 (which may correspond to
application 420 and/or application 422), a user session 522 (which
may correspond to user session 222), a session state buffer 528
(which may correspond to session state buffer 228), and a user
session state 524 (which may correspond to user session state
224).
[0036] For example, at time t0, session module 204, as part of host
506, may establish user session 522 for application 520 for a
client device (not depicted). The client device may connect to host
506 to initiate user session 522 for using application 520. User
session 522 may include state data for the user's activity using
application 520. For example, if application 520 corresponds to a
video game, user session 522 may correspond to a current state of
the user's progress in the video game.
[0037] At time t1, host 506 may detect a pause in user session 522.
The user may have minimized application 520. For example, the user
may have actively minimized application 520 or passively minimized
application 520 (e.g., the user may have shut off his or her
device, the user may have timed out, another application or program
may have minimized application 520, and/or the user may have
otherwise performed an action causing application 520 to minimize,
etc.). Accordingly, host 506 may receive a message from the client
device that indicates that user session 522 should be paused. In
other examples, host 506 may detect that the client device
disconnected from host 506. For example, the client device may have
timed out or its network connection may be intentionally or
unintentionally be disconnected. Host 506 may determine that the
client device has not responded to communications for an idle time
threshold. Thus, at time t1 as illustrated in FIG. 5, user session
522 may no longer be active for application 520.
[0038] Turning back to FIG. 1, at step 120 one or more of the
systems described herein may, in response to the detection, save a
user session state of the user session. The user session state may
include a memory state of the application corresponding to a user's
activity during the user session. For example, state module 206 may
save user session state 224 that may include a memory state of the
application for user session 222 at the time the pause is
detected.
[0039] In some embodiments, the term "session state" may refer to a
data representation of a user session which may facilitate
maintaining the user session. A session state may allow restoring a
user session by preserving a memory state (e.g., relevant data
and/or code stored in volatile and/or non-volatile memory used
during current execution of the application) of the user session.
Examples of session states include, without limitation, a memory
state stored as a backup image, virtual image, or other replica of
the memory state, a buffer dump of the current memory state, the
memory state stored in a particular format, etc.
[0040] A session state may include current configurations of the
application such that restoring the user session with the session
state may include restoring a match or near-match to the user's
experience with the application when the user session was paused.
Some applications, such as video games, file editing software,
etc., may allow the user to save a file (e.g., saving the user's
progress in the video game, saving the user's edits to a file,
etc.). Saving the file may allow the user to start a new session
with the application and load the saved progress. The user may
experience a new session, (e.g., having the application
reinitialized) having some of the user's progress restored (e.g.,
by loading the user's saved file). However, restoring a session
using a saved session state may allow the user to more closely
resume the experience when the session was paused. For example, the
session state may preserve temporary application states (e.g.,
cursor location, selections or other configurations made, etc.) as
well as other unsaved progress. For example, if the user is playing
a video game, the user may experience, for a new session,
reinitializing the game and loading the user's saved game progress.
However, if the user is reconnecting and restoring the user's
previous session, the user may experience picking back up the game
at the moment the session was paused as if the session were not
interrupted.
[0041] The systems described herein may perform step 120 in a
variety of ways. In one example, as illustrated in FIG. 5, at time
t1 user session 522 may be stored as user session state 524. Host
506, after detecting the pause in user session 522, may store user
session 522 as user session state 524, for instance by performing a
memory dump of user session 522, formatting data needed for
restoring user session 522, etc.
[0042] At step 130 one or more of the systems described herein may
determine, based on one or more session characteristics relating to
the user session, a session preservation time for preserving the
user session state. The session preservation time may correspond to
a predicted time for keeping the user session alive. For example,
preservation module 208 may determine session preservation time 226
for preserving user session state 224.
[0043] In some embodiments, the term "session preservation time"
may refer to a time for retaining a session state, which may
further correspond to a time for keeping a corresponding user
session alive. The session preservation time may correspond to a
minimum time or floor for keeping the user session alive. In other
words, after the session preservation time elapses, the
corresponding session may not be guaranteed to be recoverable.
After the session preservation time elapses, the corresponding
session state may be deleted to free up resources (e.g., free up
storage and/or memory for holding other session states).
[0044] The systems described herein may perform step 130 in a
variety of ways. In one example, preservation module 208 may
analyze various signals to predict how long to preserve user
session 222. Session preservation time 226 may correspond to a
predicted minimum time for storing user session state 224 such that
user session state 224 may be available to restore user session 222
when the user reconnects without requiring indefinite storage of
user session state 224.
[0045] For example, as illustrated in FIG. 5, the user (e.g.,
user's client device) may reconnect to host 506 at time t1 to
resume user session 522 after pausing user session 522 at time t1.
If user session state 524 is stored indefinitely, the user may
resume user session 522 at any t2 after t1. However, because
storing user session state 524 indefinitely may not be feasible,
user session 522 may only be restored at a time t2 prior to
deleting user session state 524. A corresponding session
preservation time (e.g., session preservation time 226) may ensure
that for a time t2 in which the session preservation time is
greater than t2-t1, user session state 524 may be preserved and
user session 522 may be restored. Thus, preservation module 208 may
analyze various signals to predict an expected t2 for the user to
reconnect to the session and accordingly determine a corresponding
session preservation time 226.
[0046] In some examples, preservation module 208 may analyze
session characteristics including an application characteristic of
the application, a popularity of the application, or a return rate
of users of the application. Certain types of applications may
exhibit certain session behaviors. For example, entertainment
applications (e.g., video games, social media applications, etc.)
may exhibit short sessions with frequent pauses in sessions, and
short time periods for resuming sessions. Entertainment
applications may be associated with shorter session preservation
times, which may further correspond to faster return rates of
users. Productivity applications (e.g., office applications,
specialized software for jobs, etc.), may exhibit longer sessions
with less frequent pauses in sessions, and longer time periods for
resuming sessions. Productivity applications may be associated with
longer session preservation times, which may also correspond to
slower return rates for users. Other characteristics of the
application may be factored into the session preservation time. For
instance, a popular application may exhibit a high turnover rate
for sessions, which may be associated with shorter session
preservation times to account for the high turnover. Resource
requirements for the application may also factor into the session
preservation time. For example, an application requiring large
session states may be associated with shorter session preservation
times compared to an application with small session states, in
order to utilize limited resources more efficiently.
[0047] In other examples, preservation module 208 may analyze
session characteristics including an application usage pattern of a
user, or a return rate of the user. The user himself or herself may
exhibit particular session behavior as may be determined from the
user's history. For example, a given user may be inclined to use a
given application at certain times of the day such that session
preservation time 226 may account for the user's usage pattern.
Session preservation time 226 may be longer when overlapping the
expected use time (e.g., due to a higher probability of the user
reconnecting to the session) and/or may be shorter otherwise. In
another example, a given user's application usage pattern may
indicate that the user tends to return quickly to sessions (which
may correspond to shorter times for session preservation time 226)
or may tend to return slowly to sessions (which may correspond to
longer times for session preservation time 226). In some examples,
the user may indicate, either via settings or at the time of
pausing user session 222, whether the user expects and/or intends
to return to user session 222 after a different than normal
relative time (e.g., faster than average for the user and/or class
of users, slower than average) and/or absolute time (e.g.,
indicating a specific expected return time such as within 1 hour or
at a time such as 7:00 PM). In some examples, preservation module
208 may use an average reconnection time (e.g., average time for
the user to reconnect to a given session) for determining session
preservation time 226. For example, the average reconnection time
may be used as a basis for session preservation time 226 that may
be further modified based on the factors described herein.
[0048] Preservation module 208 may further consider additional
factors and use various analysis schemes, such as statistical
analysis, machine learning, etc., to balance optimal usage of
available storage for session states with minimizing dropped
sessions for users. In some examples, preservation module 208 may
dynamically update session preservation time 226 based on success
rates (e.g., session reconnects before deleting corresponding
session states) of prior session preservation times.
[0049] At step 140 one or more of the systems described herein may
store the saved user session state in a session state buffer for at
least the determined session preservation time. For example, buffer
module 210 (and/or preservation module 208) may store user session
state 224 in session state buffer 228 for at least a time indicated
by session preservation time 226.
[0050] Session state buffer 228 may correspond to any data
structure implemented with any storage and/or memory device as
described herein. For example, session state buffer 228 may be a
queue, stack, heap, vector, array, series of registers, etc. FIG. 6
illustrates a session state buffer 628 which may correspond to
session state buffer 228 and/or session state buffer 528. Session
state buffer 628 is illustrated in FIG. 6 as an array, although in
other examples session state buffer 628 may correspond to any other
suitable data structure.
[0051] As illustrated in FIG. 6, session state buffer 628 may be
associated with multiple user session states such as a user session
state 624A, a user session state 624B, a user session state 624C, a
user session state 624D, a user session state 624E, and a user
session state 624N, each of which may correspond to different
iterations of user session state 224 and/or user session state 524.
Session state buffer 628 may be restricted in a number of user
session states that session state buffer 628 may store.
[0052] Buffer module 210 may store user session states (e.g., at
least user session states 624A, 624B, 624D, 624E) with
corresponding session preservation times for each state. Buffer
module 210 may store the corresponding session preservation times
with each state (e.g., as a flag, bit, metadata, or other status
indicator). Alternatively or in addition, buffer module 210 may
maintain a lookup table or similar data structure for correlating
session preservation times with session states.
[0053] As will be described further below, buffer module 210 may
periodically and/or automatically flush stale entries (e.g., user
session states having elapsed or expired session preservation
times) from session state buffer 628. However, when adding a new
user session state (e.g., user session state 624N) to session state
buffer 628 when full, buffer module 210 may select one of the
stored user session states for flushing. Buffer module 210 may
select a candidate user session state for flushing based on, for
example, a time to expire (e.g., a user session state having a
session preservation time that is close to or already lapsed may be
more likely to be selected), a time in buffer (e.g., a user session
state having been stored in session state buffer 628 longer than
other user session states may be more likely to be selected),
and/or other factors to determine which user session state may be
flushed with a least impact to overall user experiences (e.g., a
user session unlikely or least likely to be reconnected). As
illustrated in FIG. 6, buffer module 210 have selected and flushed
user session state 624C to provide space for storing user session
state 624N. In other examples, as will be discussed further below,
user session state 624C may be flushed in other circumstances.
[0054] Returning to method 100, the systems described herein may
perform step 140 in a variety of ways. In one example, as
illustrated in FIG. 5, at time t1 buffer module 210 may store user
session state 524 in session state buffer 528. At time t1,
application 520 may no longer be active with user session 522 and
instead the user session may be preserved as user session state 524
in session state buffer 528.
[0055] In some examples, session module 204 may detect, before
session preservation time 226 elapses, a reconnection of user
session 222. For example, in FIG. 5, time t2 may correspond to a
time before the session preservation time for user session state
524 expires such that user session state 524 may be available for
restoring user session 522 at time t2. Session module 204 may then
load user session state 524 from session state buffer 528 to
restore user session 522 and remove user session state 524 from
session state buffer 528 (e.g., removing user session state 624C in
FIG. 6). Restoring user session 522 may include restoring an
application state for application 520 similar to that at time t1,
which may include restoring data in volatile and/or non-volatile
memory using data stored in user session state 524. The user may
experience user session 522 as if there was little or no
interruption to user session 522.
[0056] In some examples, session module 204 may track a
reconnection time of user session 522. An average reconnection time
for the user may be updated based on this reconnection time such
that preservation module 208 may use the updated average
reconnection time for determining session preservation times.
[0057] As described herein, successfully predicting a session
preservation time may reduce a likelihood that a user will not be
able to reconnect to a paused session. Thus, at time t2 in FIG. 5,
user session 522 may be restored. However, if the corresponding
session preservation time is too short, then at time t2, user
session state 524 may have already been flushed such that user
session 522 may not be restorable. In some examples, preservation
module 208 may track successful and/or unsuccessful session
preservation times along with a delta between the session
preservation time and the actual reconnect time to improve
predictions of session preservation times.
[0058] Turning back to FIG. 1, at step 150 one or more of the
systems described herein may remove the user session state from the
session state buffer after the session preservation time elapses.
For example, buffer module 210 may remove user session state 224
from session state buffer 228 after session preservation time 226
elapses.
[0059] The systems described herein may perform step 150 in a
variety of ways. In one example, buffer module 210 may
automatically and/or periodically check whether each user session
state in session state buffer 228 is valid or have elapsed. In some
examples, preservation module 208 may dynamically update session
preservation time 226 such that buffer module 210 may require
active management and flushing of stale entries. In other examples,
buffer module 210 may be given instructions to flush a particular
entry. For example, the user may indicate that the user does not
intend to reconnect to a session such that buffer module 210 may be
instructed to flush the corresponding user session state. In
another example, the user's account may be terminated or otherwise
suspended such that all of the user's session states may be
flushed. In yet another example, the corresponding application may
have changed (e.g., updated, modified, deleted, etc.), such that
related user session states may no longer be data compliant with
the application and therefore may be flushed.
[0060] By identifying and flushing stale entries, buffer module 210
may maintain session state buffer 228 such that new entries may be
added. For example, in FIG. 6, flushing user session state 624C
from session state buffer 628 may allow storing user session state
624N.
[0061] As referenced above, the systems and methods described
herein are directed to dynamic resource allocation for managing
user session states. A cloud application platform may provide a
user with virtualized access to an application. On a client device,
the user may normally expect to be able to pause a current
application session and later seamlessly return to the session.
However, providing such an experience via a server hosting a
virtualized application may be prohibitively resource (e.g.,
memory) intensive. For example, keeping a user session alive may
require saving the user's session state, which may be a waste of
resources if the user does not intend to reconnect to the same
session. The systems and methods described herein may determine
which user sessions to keep alive and which user sessions to close
in order to free up resources. The systems and methods described
herein may use various signals, such as aspects relating to the
application and aspects relating to the user, to determine how long
to preserve each session.
Example Embodiments
[0062] Example 1: A computer-implemented method comprising: (i)
detecting, by a cloud-based software distribution host providing
cloud-based access to an application to a client device, a pause in
a user session of the application; (ii) in response to the
detection, saving a user session state of the user session, wherein
the user session state includes a memory state of the application
corresponding to a user's activity during the user session; (iii)
determining, based on one or more session characteristics relating
to the user session, a session preservation time for preserving the
user session state, wherein the session preservation time
corresponds to a predicted time for keeping the user session alive;
(iv) storing the saved user session state in a session state buffer
for at least the determined session preservation time; and (v)
removing the user session state from the session state buffer after
the session preservation time elapses.
[0063] Example 2: The method of Example 1, further comprising:
detecting, before the session preservation time elapses, a
reconnection of the user session; and loading the user session
state from the session state buffer to restore the user
session.
[0064] Example 3: The method of Example 2, further comprising
tracking a reconnection time of the user session, wherein the one
or more session characteristics includes an average reconnection
time for the user and the session preservation time is further
based on the average reconnection time.
[0065] Example 4: The method of Examples 1, 2, or 3, wherein the
one or more session characteristics includes at least one of an
application characteristic of the application, a popularity of the
application, or a return rate of users of the application.
[0066] Example 5: The method of any of Examples 1-4, wherein the
one or more session characteristics includes at least one of an
application usage pattern of a user, or a return rate of the
user.
[0067] Example 6: The method of any of Examples 1-5, wherein the
pause corresponds to at least one of the client device
disconnecting from the cloud-based software distribution host, or
the user minimizing the application.
[0068] Example 7: The method of any of Examples 1-6, wherein the
application comprises a video game and the user session state
corresponds to a progress of the user in the video game.
[0069] Example 8: A system comprising: at least one physical
processor; physical memory comprising computer-executable
instructions that, when executed by the physical processor, cause
the physical processor to: (i) detect, by a cloud-based software
distribution host providing cloud-based access to an application to
a client device, a pause in a user session of the application; (ii)
in response to the detection, save a user session state of the user
session, wherein the user session state includes a memory state of
the application corresponding to a user's activity during the user
session; (iii) determine, based on one or more session
characteristics relating to the user session, a session
preservation time for preserving the user session state, wherein
the session preservation time corresponds to a predicted time for
keeping the user session alive; (iv) store the saved user session
state in a session state buffer for at least the determined session
preservation time; and (v) remove the user session state from the
session state buffer after the session preservation time
elapses.
[0070] Example 9: The system of Example 8, wherein the instructions
further comprise instructions for: detecting, before the session
preservation time elapses, a reconnection of the user session; and
loading the user session state from the session state buffer to
restore the user session.
[0071] Example 10: The system of Example 9, wherein the
instructions further comprise instructions for tracking a
reconnection time of the user session, wherein the one or more
session characteristics includes an average reconnection time for
the user and the session preservation time is further based on the
average reconnection time.
[0072] Example 11: The system of Example 8, 9, or 10, wherein the
one or more session characteristics includes at least one of an
application characteristic of the application, a popularity of the
application, or a return rate of users of the application.
[0073] Example 12: The system of any of Examples 8-11, wherein the
one or more session characteristics includes at least one of an
application usage pattern of a user, or a return rate of the
user.
[0074] Example 13: The system of any of Examples 8-12, wherein the
pause corresponds to at least one of the client device
disconnecting from the cloud-based software distribution host, or
the user minimizing the application.
[0075] Example 14: A non-transitory computer-readable medium
comprising one or more computer-executable instructions that, when
executed by at least one processor of a computing device, cause the
computing device to: (i) detect, by a cloud-based software
distribution host providing cloud-based access to an application to
a client device, a pause in a user session of the application; (ii)
in response to the detection, save a user session state of the user
session, wherein the user session state includes a memory state of
the application corresponding to a user's activity during the user
session; (iii) determine, based on one or more session
characteristics relating to the user session, a session
preservation time for preserving the user session state, wherein
the session preservation time corresponds to a predicted time for
keeping the user session alive; (iv) store the saved user session
state in a session state buffer for at least the determined session
preservation time; and (v) remove the user session state from the
session state buffer after the session preservation time
elapses.
[0076] Example 15: The non-transitory computer-readable medium of
Example 14, wherein the instructions further comprise instructions
for: detecting, before the session preservation time elapses, a
reconnection of the user session; and loading the user session
state from the session state buffer to restore the user
session.
[0077] Example 16: The non-transitory computer-readable medium of
Example 15, wherein the instructions further comprise instructions
for tracking a reconnection time of the user session, wherein the
one or more session characteristics includes an average
reconnection time for the user and the session preservation time is
further based on the average reconnection time.
[0078] Example 17: The non-transitory computer-readable medium of
Example 14, 15, or 16, wherein the one or more session
characteristics includes at least one of an application
characteristic of the application, a popularity of the application,
or a return rate of users of the application.
[0079] Example 18: The non-transitory computer-readable medium of
any of Examples 14-17, wherein the one or more session
characteristics includes at least one of an application usage
pattern of a user, or a return rate of the user.
[0080] Example 19: The non-transitory computer-readable medium of
any of Examples 14-18, wherein the pause corresponds to at least
one of the client device disconnecting from the cloud-based
software distribution host, or the user minimizing the
application.
[0081] Example 20: The non-transitory computer-readable medium of
any of Examples 14-19, wherein the application comprises a video
game and the user session state corresponds to a progress of the
user in the video game.
[0082] As detailed above, the computing devices and systems
described and/or illustrated herein broadly represent any type or
form of computing device or system capable of executing
computer-readable instructions, such as those contained within the
modules described herein. In their most basic configuration, these
computing device(s) may each include at least one memory device and
at least one physical processor.
[0083] In some examples, the term "memory device" generally refers
to any type or form of volatile or non-volatile storage device or
medium capable of storing data and/or computer-readable
instructions. In one example, a memory device may store, load,
and/or maintain one or more of the modules described herein.
Examples of memory devices include, without limitation, Random
Access Memory (RAM), Read Only Memory (ROM), flash memory, Hard
Disk Drives (HDDs), Solid-State Drives (SSDs), optical disk drives,
caches, variations or combinations of one or more of the same, or
any other suitable storage memory.
[0084] In some examples, the term "physical processor" generally
refers to any type or form of hardware-implemented processing unit
capable of interpreting and/or executing computer-readable
instructions. In one example, a physical processor may access
and/or modify one or more modules stored in the above-described
memory device. Examples of physical processors include, without
limitation, microprocessors, microcontrollers, Central Processing
Units (CPUs), Field-Programmable Gate Arrays (FPGAs) that implement
softcore processors, Application-Specific Integrated Circuits
(ASICs), portions of one or more of the same, variations or
combinations of one or more of the same, or any other suitable
physical processor.
[0085] Although illustrated as separate elements, the modules
described and/or illustrated herein may represent portions of a
single module or application. In addition, in certain embodiments
one or more of these modules may represent one or more software
applications or programs that, when executed by a computing device,
may cause the computing device to perform one or more tasks. For
example, one or more of the modules described and/or illustrated
herein may represent modules stored and configured to run on one or
more of the computing devices or systems described and/or
illustrated herein. One or more of these modules may also represent
all or portions of one or more special-purpose computers configured
to perform one or more tasks.
[0086] In addition, one or more of the modules described herein may
transform data, physical devices, and/or representations of
physical devices from one form to another. For example, one or more
of the modules recited herein may receive session data to be
transformed, transform the session data, output a result of the
transformation to manage session data, use the result of the
transformation to maintain the session data, and store the result
of the transformation to store the session data. Additionally or
alternatively, one or more of the modules recited herein may
transform a processor, volatile memory, non-volatile memory, and/or
any other portion of a physical computing device from one form to
another by executing on the computing device, storing data on the
computing device, and/or otherwise interacting with the computing
device.
[0087] In some embodiments, the term "computer-readable medium"
generally refers to any form of device, carrier, or medium capable
of storing or carrying computer-readable instructions. Examples of
computer-readable media include, without limitation,
transmission-type media, such as carrier waves, and
non-transitory-type media, such as magnetic-storage media (e.g.,
hard disk drives, tape drives, and floppy disks), optical-storage
media (e.g., Compact Disks (CDs), Digital Video Disks (DVDs), and
BLU-RAY disks), electronic-storage media (e.g., solid-state drives
and flash media), and other distribution systems.
[0088] The process parameters and sequence of the steps described
and/or illustrated herein are given by way of example only and can
be varied as desired. For example, while the steps illustrated
and/or described herein may be shown or discussed in a particular
order, these steps do not necessarily need to be performed in the
order illustrated or discussed. The various exemplary methods
described and/or illustrated herein may also omit one or more of
the steps described or illustrated herein or include additional
steps in addition to those disclosed.
[0089] The preceding description has been provided to enable others
skilled in the art to best utilize various aspects of the exemplary
embodiments disclosed herein. This exemplary description is not
intended to be exhaustive or to be limited to any precise form
disclosed. Many modifications and variations are possible without
departing from the spirit and scope of the present disclosure. The
embodiments disclosed herein should be considered in all respects
illustrative and not restrictive. Reference should be made to the
appended claims and their equivalents in determining the scope of
the present disclosure.
[0090] Unless otherwise noted, the terms "connected to" and
"coupled to" (and their derivatives), as used in the specification
and claims, are to be construed as permitting both direct and
indirect (i.e., via other elements or components) connection. In
addition, the terms "a" or "an," as used in the specification and
claims, are to be construed as meaning "at least one of." Finally,
for ease of use, the terms "including" and "having" (and their
derivatives), as used in the specification and claims, are
interchangeable with and have the same meaning as the word
"comprising."
* * * * *