Client device configuration based on client context

The described technology is generally directed towards configuring a client device with client configuration data based on client context data. The configuration data can include endpoints of various services to which the client can connect that are appropriate for the client device based on the client context data, along with dimension information (route key values) for connecting to each such service. For example, a roaming client device can be given an endpoint and dimension information to connect to a content service in the roaming region, with a different endpoint and dimension information for communicating user information to a home region to which the user is affiliated. This facilitates single hop/reduced latency for content requests, and compliance with home regulations via a single hop to the home service.

BACKGROUND

When dealing with a single product distributed globally among client devices, a typical implementation is to have a single common endpoint or DNS (domain name service) entry that resolves to multiple canonical names (CNAMEs). The IP address on the request is then used to pick the CNAME that is geographically closest to the caller.

This simple approach works when there is only a first boundary service call that needs geolocation-based resolution, because there is additional latency involved with the extra lookup. However, when there are multiple boundary services or different domains with different constraints and deployment architectures, this simple approach is inadequate.

DETAILED DESCRIPTION

The technology described herein is generally directed towards configuring a client device to route requests from the client device to a correct service in a global environment, based on the client device's current client context during a client session and what the client is requesting. Each such service can be part of a group of globally distributed services and or microservices.

Once the client device is initially configured for a session, any request during that session is automatically routed to the appropriate service endpoint. As one example, client user-related data is communicated to and from a user service geographically located in the client user's registered home region location, regardless of where the client device is currently located. In the same session, client content-related data (e.g., video streaming content) data is communicated to and from a content service geographically located in the client device's current location.

Thus, in a more particular example, a European Union-based client user who is roaming in the United States will send user-related data requests directly to an endpoint corresponding to a user service physically located in the European Union, while content-related data requests will be sent to a content service geographically located in the United States. As will be understood, with the technology described herein, the user-related data thus does not have any additional hop or hops through a United States located service, and for example need not be further processed (e.g., sanitized) to meet European Union data privacy regulations. The content-related data, such as request for a catalog of current streaming video content offerings, will be sent to a service located in the United States region, and thus will return the catalog of offerings that is currently available in the United States. Note that this is in contrast to alternative solutions that route client requests to a nearest geographic service, followed by rerouting the request via one or more additional hops to the appropriate service,

It should be understood that any of the examples herein are non-limiting. For instance, a client's user-related data requests versus content-related data requests are used as examples that are relatively straightforward to understand, however there are other client types of requests, such as a request to an authentication service, that are similarly each sent to an appropriate authentication service based on the client configuration. As another alternative, certain configuration-related data structures are described, including templates, dimension information, route key data, and endpoint data, however other suitable ways and/or structures to maintain and communicate such data can be used.

FIG.1is a generalized block diagram representation of an example system100in which client devices102(1)-102(n) are associated with a global platform, such as client devices operated by valid subscribers of a global streaming video content provider. The global platform can comprise services and/or microservices in various servers including cloud services or the like located worldwide.

Each client device102(1)-102(n) has a current client context; client context data104(1) and104(2) are depicted inFIG.1. Client context data for a given client device can include (but is not limited to) the current client device location, the client device type, software version of the client application program that couples to the global platform, user information such as subscriber entitlement data, subscriber's home location, and so forth.

In general, the client devices (e.g.,102(1) and102(2)) make respective client configuration requests (e.g.,106(1) and106(2)) to a client configuration service108. There can be a single client configuration service108as shown inFIG.1, or there can be specific, global or local, endpoints or services (e.g., using latency based routing or the like) that return the configuration information110(1) and110(2) based on the client context data. In one implementation, the client context data is known for each client request from a token associated with the request.

In general and as described herein, the configuration information comprises endpoint data for various services to which the client device is to connect, along with dimension data for connecting to those services. In one implementation, the dimension data comprises a number of variables that correspond to route key data.

Subsequent, post-configuration requests (e.g.,112(1) and112(2)) are thus routed to and responded by an appropriate service (e.g., one of the client configuration-based services114-117) based on the endpoint configured for the type of request being made. Note that although four such services114-117are depicted inFIG.1, there can be on the order of hundreds or thousands of such services in an actual global platform.

In this way, for example, a first client device such as the device102(1) located in region X receives endpoints and dimension/route key data for connecting to a content service (e.g.,114) in region X, while a second client device such as102(2) located in region Y receives endpoints and dimension/route key data for connecting to a content service (e.g.,117) in region Y. As will be understood, user-related data is routed via an appropriate endpoint based on the client user's (e.g., subscriber's) home location specified in or determinable from the client context data, regardless of whether the corresponding device being used by that client user is currently within the user's home location or is currently roaming in a different region.

FIG.2is a further example, in which a client device202has identified itself as a valid client, and requests (block206) configuration from a client configuration service208, e.g., using a routing method such as, but not limited to, latency based routing, geo-IP based routing, or the like. There are various well-known ways for a client to login/identify/authenticate itself as a valid client for a session, and as such are not described hereinafter except to note that a token or other data can be obtained by the client device and then used thereafter during a session.

In the example ofFIG.2, the client device receives a configuration data structure (block210) with route keys by querying any or a specific, global or local, endpoint or service that vends route keys (shown inFIG.2as the client configuration service208). The route keys specify the values for each dimension to be used in connecting to a service. In one implementation, the route keys populate a structured logical name template for the endpoint or service.

The client uses a combination of the template and the service name (e.g., EU.content can indicate a content user to a specific European Union endpoint including domain) to identify the correct logical service to which to send requests at a given point in time. Any network layer protocol (like IPv4/IPv6)-based routing can be used to translate the logical service name to the physical IP address.

In the example ofFIG.2, once configured with the configuration information (endpoint data and dimension data), a user data-related request212is thus correctly routed to the user service214, which returns an appropriate response216. A content data-related request218is correctly routed to the content service220, which returns an appropriate response222.

FIG.3exemplifies how the client configuration information can be used to couple to an appropriate service during a session. Consider that in this example, a client user has a home locale such as the European Union, but is currently roaming on a device302in a roaming locale such as Latin America (or a specific country therein). This information is part of the current client context data. There is thus a user home roaming partition for user data and a content roaming locale partition for content data. Note that in addition to partitioning by region, partitions can be based on devices (e.g., different device types), or other parameters.

Once the client device302receives the configuration information310based on the current client context, the client device302will send client user-related data requests312to a user data service314in the user's home locale. These can be requests to obtain user data, and/or to store user data (e.g., with a data response or acknowledgement response from the service314). The client device302will send content-related data requests to a content data service320in the current roaming locale, and thereby receive content322appropriate for (e.g., currently available for streaming in) the roaming locale.

Configuring the client based on the current client context at the session runtime is thus significantly advantageous in various ways. In the example ofFIG.3, certain client requests such as involving content can be routed to functionally correct endpoints with the lowest latency, based on the current locale. Other client requests such as involving user data can be sent to other functionally correct endpoints based on concepts such as legal jurisdiction, regulatory requirements and the like.

The configuration information (e.g., including the route keys comprising the values for each dimension) is refreshed based on current parameters according to certain conditions that, for example, make a route key(s) no longer relevant. For example, any change to the value of at least one of the dimensions results in a reconfiguration of the client, at least with respect to the changed dimension. For example, if a user travels from Sweden to Spain, the value in the content dimension changes such that the content partition changes to Spain's content partition.

Further, route keys expire after a certain period of time, e.g., when a user token expires. Reconfiguration of the client device occurs in response to route key/token expiration. Another reconfiguration is based on backup paths being triggered if any of the endpoints identified in the configuration information become unreachable for any of numerous possible reasons, such as the client being out of region for that endpoint, the endpoint fails, and so forth.

FIG.4illustrates the concept of templates, which can, for example, be tailored to a particular user experience. For example, instead of determining the client configuration information based on processing the client context data as it is received, the client configuration information can be maintained in an already existing, named template data structure that is matched to the client context data. As a more particular example, consider that there is one existing template for European Union clients roaming in Canada that have a mobile device type J running software version K, and another existing template for European Union clients roaming in Canada that have a (more powerful) personal computer running software version L. A first template can be matched and returned based on the first set of client context data for the mobile device type J running software version K, and second first template can be matched and returned based on the second set of client context data for the personal computer running software version L. As is understood, any device capable of running the client application program can be used, e.g., a set top box, a tablet computing device, and so on, and there can be different classes and subclasses of devices, e.g., different mobile phone devices from vendors or different versions from the same vendor, and so forth.

InFIG.4, a client device402(1) has one set of client context data, which is received via a configuration request406(1) at a client configuration service408. Another client device402(2) has another set of client context data, which is received via a configuration request406(2) at the client configuration service408(or possibly a different configuration service). In this example, the client configuration service408incorporates or is coupled to template matching logic440that determines a template444(1) (e.g., found in a templates data store442) that is appropriate for the client context data of the client device402(1). The template444(1) is thus returned in the configuration response410(1) to the client device402(1). For the client device402(2) with its configuration request406(2), the template matching logic440determines a template444(2) that is appropriate for the client context data of the client device402(2). The template444(2) is thus returned in the configuration response410(2) to the client device402(2). Note that the templates data store442or the like can be replicated or be accessible to multiple client configuration services.

Although not explicitly shown inFIG.4, there can be a default template in each client, and the service can send the parameters to populate the built-in template, or send updated templates. It is feasible for clients to cache templates, and for example have the configuration service return a template identifier that is appropriate for the current client context. The service can also optionally support creation of templates or updates to existing templates, and assign templates to specific endpoints or groups of endpoints

FIG.4shows another concept, namely optional features446(1) and446(2) which can be included with endpoints, and which can be used to configure the experience of the user, particular in (but not limited to) a client in an unauthenticated state. Features can accompany configuration information/a template, and for example, can facilitate region based flagging, such as when user consent (e.g., based on regional privacy configuration defaults) is needed to perform some action. As another example, a feature can be returned regarding a minimum client version supported in a region and environment, such as to recognize that a client device's old software version is not valid in a current region, whereby via interaction with the user, the client device can obtain an update.

FIG.5is an example sequence diagram showing interactions between various entities that are related to dynamically configuring a client device502in one example implementation. InFIG.5, to obtain or refresh a token (block550) the client communicates via a “GET Tokens” call with client token and other data to a token service552or the like. This can be a known token initialization or refresh, that validates the client and converts a client token to a user token.

In this example, the client is properly authenticated and receives the user token for use in further communications, including for obtaining configuration information (block554) as described herein. In one implementation, the configuration service can comprise a combination of a (local or global) boundary service556, a configuration and policy service558, and a geolocation service560; that is, the client502interacts with the boundary service502, which in turn calls the geolocation service560, and the configuration and policy service558.

For example, the geolocation service560can determine the location of the client device502, (and possibly override the actual location for privileged users, such as developers and testers of the platform), and return the geolocation data to the boundary service556. In turn, based on the location, the boundary service556calls the configuration and policy service558, which determines the client configuration information as described herein, including any optional feature data; for example, minor policy data such as “no longer support this build” can be determined. This is returned to the client device via the boundary service556.

In this way, the client receives appropriate endpoints for a list of services, based on the client IP address and location, device type (which can change configuration) location parameters to support, which can be based on software build and so on; (note that there can be a “special” software build for testing purposes). The many dimensions identify the correct environment, correct domain, correct geography and correct version of a service applicable to each client request. From a maintainability perspective, having a relatively small number of configurable clients is valuable, as the number and variety of devices a person uses keeps increasing. Therefore, there is value to methodically and efficiently determining the endpoints to which any client needs to connect, subject to the constraints in these various dimensions. Clients can thus communicate with microservices having different semantics and characteristics around the world, yet without extra hops to a home service.

In summary, the roaming capabilities means that client applications need to talk to different regional service instances or services depending on the user's current geolocation and applicable policies. To support this roaming ability, the technology described herein, via the configuration service, supplies the client with session-specific uniform resource locators (URLs) or the like for any endpoints invoked directly by the client.

Other aspects of the client configuration can vary based on the factors described herein. For example, the client may need to disable or filter certain third-party integrations. To support client configuration, the configuration service provides a set of named configuration objects for use by the client.

Client endpoint configuration assumes that endpoints referenced directly from the various clients are organized in some way, such as endpoints that provide specific functionality with an implied contract. An endpoint resolves to a URL (e.g., via an API on a common client library. Domains can correspond loosely to individual service domains in the application; each endpoint is associated with some domain. In one implementation, domains supply a base URL for endpoints on the domain and an optional ‘ext’ parameter which indicates that the service is external.

Routing keys can be used to construct base URLs for each of the domains, as domain URLs typically follow a small number of consistent patterns. When a new configuration is requested, the client sends a configuration version identifier that indicates the set of required endpoints needed by the client as well as the domains and routing keys that are used in the implementation.

One or more aspects can be embodied in a system, such as represented inFIG.6, and for example can comprise a memory that stores computer executable components/instructions, and a processor that executes computer executable components/instructions stored in the memory to perform operations. Example operations can comprise operation602, which represents receiving, from a client device, a client request for client configuration data, the client request associated with client context data. As represented by operation604, in response to the request, operations include determining, based on the client context data, dimension information and endpoint data applicable to the client request (operation606), determining route key data for populating a client-side data structure for an endpoint to which the client device is to connect, the route key data comprising the dimension information (operation608), and sending the client configuration data comprising the route key data and endpoint data to the client device (operation610).

Further operations can include determining, based at least one of the client context data and the user context data, session configuration information comprising at least one of: endpoint data and dimension data applicable to the client request

The client context data can include at least one of client device location data, client device type data, or client software type data.

The dimension information can include at least one of: environment data corresponding to a service applicable to the client request, domain data corresponding to a service applicable to the client request, geographic data corresponding to a service applicable to the client request, or version data corresponding to a service applicable to the client request.

The endpoint data can correspond to a service.

Further operations can include detecting a change to the dimension information, and in response to detecting the change, refreshing the route key data with refreshed route key data based on the change to the dimension information, and sending refreshed client configuration data comprising the refreshed route key data to the client device.

Further operations can include detecting expiration of the route key data, and in response to detecting the expiration, refreshing the route key data with refreshed route key data based on the expiration, and sending refreshed client configuration data comprising the refreshed route key data to the client device.

Further operations can include detecting an unreachable endpoint associated with the endpoint data, and in response to detecting the unreachable endpoint, refreshing the client configuration data with refreshed endpoint data comprising a backup path to another endpoint, and sending refreshed client configuration data to the client device.

The client-side data structure can include a structured template, and the route key data can be configured for populating the structured template.

Further operations can include creating a new structured template, and sending the new structured template to the client device.

Further operations can include updating the structured template to an updated structured template, and sending the updated structured template to the client device.

Further operations can include determining feature data based on the client context data, and sending the feature data to the client device.

The feature data can include at least one of: regional configuration data corresponding to region information identified from the client context data, regional uniform resource locator data corresponding to region information identified from the client context data, regional default data corresponding to region information identified from the client context data, regional privacy configuration information corresponding to region information identified from the client context data, or client software version-related information.

One or more example aspects, such as corresponding to operations of a method, are represented inFIG.7. Operation702represents sending, from a client device comprising a processor, client context data to a client configuration service. Operation704represents receiving, by the client device from the client configuration service, client configuration data comprising dimension information and endpoint data based on the client context data. Operation706represents populating, by the client device based on the dimension information, a data structure for an endpoint, identified in the endpoint data, to which the client device is to connect; (note that the client can select a semantically distinct end point instance(s). For example, a home page in Swedish is a logical abstraction which can be rendered by a semantically distinct service in the EMEA region. The mapping of that semantic endpoint to a physical location is done using standard network layer protocols). Operation708represents communicating, by the client device, the data structure to the endpoint; Operation710represents receiving, by the client device from a service associated with the endpoint, response data based on the dimension information.

The client context data can identify a current region of the client device, and receiving the response data can include receiving user experience defining data associated with the current region. There can be direct calls to services associated with content (e.g., usually in the current region, not the user's home region, passing user information to other calls, and/or service-to-service calls from the content locale to the user locale.

The client context data can identify a user identity of a user of the client device, the endpoint data can include a service located within a user locale associated with the user identity, and receiving the response data can include receiving user data associated with the user locale.

Operations can include receiving, by the client device from the client configuration service, feature data, and responding to the client configuration service based on the feature data.

FIG.8summarizes various example operations, e.g., corresponding to executable instructions of a machine-readable medium, in which the executable instructions, when executed by a processor, facilitate performance of the example operations. Operation802represents receiving, from a client device, a client request for client configuration data, the client request associated with client context data. Operation804represents, in response to the request, determining, based on user data location information in the client context data, first dimension information and first endpoint data applicable to the client request (operation806), determining, based on device current region data in the client context data, second dimension information and second endpoint data applicable to the client request; (operation808), and sending the client configuration data comprising the first dimension information, the first endpoint data, the second dimension information and the second endpoint data to the client device (operation810).

Further operations can include sending feature data to the client device.

Determining the first dimension information and first endpoint data applicable to the client request can include determining first route key data for communicating with a user data service corresponding to the first endpoint, and determining the second dimension information and the second endpoint data applicable to the client request can include determining second route key data for communicating with a content service corresponding to the second endpoint.

As can be seen, there is described a technology in which client requests belonging to the same domain need only one initial lookup of the correct domain to route the requests, instead of introducing an extra hop of latency and traffic to the global or local endpoint on each request to resolve to the correct endpoint, such as when there are multiple domains domiciled in different geographical regions due to business constraints, for example. The technology thus reduces the unnecessary hops, traffic and latency via one initial lookup for client configuration, followed by efficient routing to the correct domain specific services.

The technology can perform client to service routing with minimal hops using templated route keys. Benefits include, but are not limited to, reduction of network traffic through more efficient routing from clients, reduction of latency experienced by the user through more efficient routing from clients, partitioning traffic based on business rules that are difficult to infer with commodity network appliances, keeping communication between services generally to a required minimum leading to reduced cloud infrastructure network and scaling costs, and facilitating tighter remote control of clients in production environments by being able to reroute client requests with generally minimal intervention. For example, the system can work around issues with in-market clients by redirecting them based on context. The technology described herein is extensible to many types of environments.

The techniques described herein can be applied to any device or set of devices (machines) capable of running programs and processes. It can be understood, therefore, that personal computers, laptops, handheld, portable and other computing devices and computing objects of all kinds including cell phones, tablet/slate computers, gaming/entertainment consoles and the like are contemplated for use in connection with various implementations including those exemplified herein. Accordingly, the general purpose computing mechanism described below inFIG.9is but one example of a computing device.

FIG.9thus illustrates a schematic block diagram of a computing environment900with which the disclosed subject matter can interact. The system900comprises one or more remote component(s)910. The remote component(s)910can be hardware and/or software (e.g., threads, processes, computing devices). In some embodiments, remote component(s)910can be a distributed computer system, connected to a local automatic scaling component and/or programs that use the resources of a distributed computer system, via communication framework940. Communication framework940can comprise wired network devices, wireless network devices, mobile devices, wearable devices, radio access network devices, gateway devices, femtocell devices, servers, etc.

The system900also comprises one or more local component(s)920. The local component(s)920can be hardware and/or software (e.g., threads, processes, computing devices). In some embodiments, local component(s)920can comprise an automatic scaling component and/or programs that communicate/use the remote resources910and920, etc., connected to a remotely located distributed computing system via communication framework940.

One possible communication between a remote component(s)910and a local component(s)920can be in the form of a data packet adapted to be transmitted between two or more computer processes. Another possible communication between a remote component(s)910and a local component(s)920can be in the form of circuit-switched data adapted to be transmitted between two or more computer processes in radio time slots. The system900comprises a communication framework940that can be employed to facilitate communications between the remote component(s)910and the local component(s)920, and can comprise an air interface, e.g., Uu interface of a UMTS network, via a long-term evolution (LTE) network, etc. Remote component(s)910can be operably connected to one or more remote data store(s)950, such as a hard drive, solid state drive, SIM card, device memory, etc., that can be employed to store information on the remote component(s)910side of communication framework940. Similarly, local component(s)920can be operably connected to one or more local data store(s)930, that can be employed to store information on the local component(s)920side of communication framework940.

The computer1002further includes an internal hard disk drive (HDD)1014(e.g., EIDE, SATA), and can include one or more external storage devices1016(e.g., a magnetic floppy disk drive (FDD)1016, a memory stick or flash drive reader, a memory card reader, etc.). While the internal HDD1014is illustrated as located within the computer1002, the internal HDD1014can also be configured for external use in a suitable chassis (not shown). Additionally, while not shown in environment1000, a solid state drive (SSD) could be used in addition to, or in place of, an HDD1014.

Other internal or external storage can include at least one other storage device1020with storage media1022(e.g., a solid state storage device, a nonvolatile memory device, and/or an optical disk drive that can read or write from removable media such as a CD-ROM disc, a DVD, a BD, etc.). The external storage1016can be facilitated by a network virtual machine. The HDD1014, external storage device(s)1016and storage device (e.g., drive)1020can be connected to the system bus1008by an HDD interface1024, an external storage interface1026and a drive interface1028, respectively.