U.S. Pat. No. 9,262,436

Referring toFIG. 1, an online game system comprises central network facilities1provided with a central server device2, and a central memory device3in the embodiment shown. In addition, in the online game system there is a plurality of client devices4.1, . . . ,4.n. The client devices4.1, . . . ,4.nmay locally be established on a computer device, e.g. a personal computer, or a mobile communication device, such as a mobile phone. The client devices4.1, . . . ,4.nwill connect to the central network facilities1for running an online game session. Also, client devices4.1, . . . ,4.nare provided with a local memory device5.1, . . . ,5.nwhich, preferably, is comprising two ore more memory entities which may provide several hierarchically organized cache entities.

Data transfer connections between the components of the online game system will be provided permanently or non-permanently depending on different modes of operations. Data communication may be performed, for example, between the client devices4.1, . . . ,4.nand the central network facilities1. Also, there may be data transfer between the client devices4.1, . . . ,4.n. In another mode of operation, the local memory device5.1, . . . ,5.nmay receive data directly from the central memory device3. Preferably, the internet6(seeFIG. 1) will be used as part of the data transfer connections, but, also non-public network structures may be included in establishing the data transfer connections.

Following, methods are described which may be performed in the online game system. The methods disclosed provide embodiments. The methods described may be combined by performing one or more steps of one method and one or more steps of another method. Also, additional features may be added to the processes explained. Of course, in the processes of operation of the online game system as described below features may he left out, the method left still using aspects of the invention.

In the following it is assumed that for at least some of the data exchange in the online game system the HTTP protocol is used. However, the disclosure given can be applied to other protocols as well.

In pre-processing during a build-up process of a virtual file system asset data of the central network facilities1comprising a plurality of data files are prepared for use with the virtual file system which preferably may be provided as a HTTP virtual file system. All data files of the asset data are located in a single file directory tree with one root directory at the top.

Referring toFIG. 2, in a first step20each data file being part of asset data provided in the file directory is encoded by compressing the data file and processing an encoded value for the compressed data, e.g. a hash value. For each sub directory, a subdirectory content file which may also referred to as leaf table-of-content file is generated in a step21. The subdirectory content file is listing the encoded values (hash values) for all data files provided in the sub directory. Also, the subdirectory content file comprises, in addition to the encoded value, file directory path information indicating a path in the file directory where the respective data file is located in the file system. For example, the data received in the subdirectory content file for a data file may be as follows: [export_win32/anims/characters]/[ancestral_guard_variations.nax3] |f| [42c87fbbfc0e108dc3ae3ab3616c0d8b] ([name of subdirectory]/[name of data file] |f| [encoded value of data file]). The pieces of information “name of subdirectory” and “name of data file” together provide a kind of path information for the data file in the file system.

Following, in step22each subdirectory content file is compressed and encoded like the data files of the asset data.

In a step23, a single directory content file which may also referred to as table-of-content file is created which is listing all sub directories of the file system with its name and its encoded value processed for respective subdirectory content file. For example, the data received in the directory content file for a subdirectory may be as follows: [export_win32/anims/characters] |d| [5469bfde8f4012e4bedda397fe0282df] ([name of subdirectory] |d| [encoded value of subdirectory content file]).

Following, in step24the directory content file is compressed, and the encoded value (hash value) for the resulting file is computed. The single encoded value for the directory content file may be referred to as a root directory key. The root directory key is saved to a separate location in the deployment directory hierarchy accessible by the central server device (step25).

At the time of starting an online session in the client device (step26), the following steps are performed (seeFIG. 3) for finally setting-up the virtual file system. The client device receives the directory root key from the central server device in a step30. The client device reads the directory content file into its local memory device (step31), namely a RAM. At this point, the virtual file system is fully operational.

In a preferred embodiment, a Global Lookup Table is generated in the local memory device (step32). It associates each data file with the file's encoded value, for example, a data file name like the file's URL with the hash value. The URL defines the location of a data file in the tile directory. The Global Lookup Table is empty at the start of the application and is filled on-demand with downloaded data from the table-of-content files.

When an I/O request for a data file identified by its data file name (e.g., URL) is received in the client device in step33, the encoded value for the data file is looked up in the Global Lookup Table. If the URL is already in the Global Lookup Table, the encoded value for the data file requested is returned (step34). Otherwise the subdirectory content file containing the data file requested is loaded to the client device. The data file's directory path is extracted from the data file's name. Information identifying the data file's name/encoded value is added to the key/value-pairs of the Global Lookup Table.

If, after loading (all) the subdirectory content file(s), the data file's name is still not in Global Lookup Table, the data file requested does not exist on the central device side. Following, the10request is cancelled by a FileNotExists error.

The I/O request now consists of the data file's name and encoded value, and it is known that the data file does exist in the file directory. Important to note, the data file name (URL) and the encoded value are unique for this version of the data file. If the data file content changes, i.e. a new version is provided the encoded value in the subdirectory content file (table-of-content-file) will change.

Next, in step35a “TryLoadFromCache” operation is processed. A filename is built from the data file name (URL) and the encoded value identifying the current version of the data file. It is checked if a data file with this unique name exists in the local download memory device. If yes, data the data file are loaded from the local memory device instead of downloading it from the central device. If no, an operation “TryLoadFromHttpServer” is processed instead.

The operation “TryLoadFromHttpServer” provides for a normal HTTP GET for downloading the data file from central network facilities1by using the URL. The downloaded data are stored into the local memory device. A memory filename is built from the data file name (URL) and the encoded value for identifying this specific version of the data file.

The I/O request received in the client device is now basically finished, and in step36the data file's data are loaded either from the local memory device or the central network facilities1.

Optionally the actual encoded value of the loaded data file's data may be checked against the expected encoded value from the Global Lookup Table. If they don't match the file has either been tampered with, or there was an error during download.

Worth mentioning, the same process may take place when downloading the directory content file(s). Therefore, there is basically a recursive process with at most two recursion steps (data file->subdirectory content file->directory content file/directory content file).

The technology provided implements a hierarchical file-granular caching system on a fast local read/write storage device which dramatically reduces HTTP traffic (down to no HTTP traffic at all) and prevents client-side file tampering. The caching system implements the following features:does not use an expiration date like traditional browser caches, but an encoded hash of the file content to check whether a file in the cache is up-to-dateuses table-of-content files generated at build-time to associate encoded hashes with filenames and to prevent unnecessary HTTP server roundtripsno HTTP requests at all if the cache is up-to-dateprevents file-tampering by examining whether the actual content of a file in cache is identical with the server-side file by checking the actual encoded hash of a file against the expected encoded hashdata files in the cache are named as their encoded hash valuedata files in the cache are compressed (reducing cache size and increasing pre-received data throughput of the hard disc)subdirectory content files are cached just as other data files.

A cache hit is defined as one of: (i) a data file named like the encoded value of the tested data file does exist in the cache, and (ii) the actual content of this data file must match the expected (build-time) encoded value. In case of a cache-hit, the I/O request is fulfilled completely from the local cache assigned to the client device, otherwise a request, e.g. an HTTP request, will be issued which fetches the complete data files from the central server device into the local memory device, namely into the RAM and into the local file system cache assigned to the client device.

A client-side tampering protection may be implemented. For each I/O request received by the client device, the actual data file content is checked against the encoded value from the subdirectory content files. If there is a mismatch, the local file system cache assigned to the client device will report a cache mismatch. Following, the data file requested will be fetched anew from the central server device, e.g. a HTTP server, and the local cache version will be overwritten with the correct version from the server. At the same time, the hash value for the data file fetched will be processed in the local memory device and stored together with the data file.

This tampering protection works for the subdirectory content files as well. Modifying the encoded values in the subdirectory content file would cause a cache mismatch when reading the subdirectory content file itself, in turn causing it to be fetched directly from the server again. Successful client-side cache-file tampering would require modifying the root directory key which is communicated to the client device directly from the central server device at start-up. The client-side tampering-protection is preferably used in conjunction with a properly secured client/server architecture, where the client isn't allowed to manipulate sensitive game state in an online session running. Especially, the client-side tampering-protection is good for preventing client-side manipulations like so-called “wall-hacks”.

The encoded values may be used on the client device side as follows. Every I/O request on the client is associated with the encoded value, e.g. the hash value, of the data file before the data file is actually fetched from the server. The encoded value is used to check for a cache-hit, enable robust CDN support (see below), and finally to check whether the data file has been tampered within the local cache assigned to the client device.

There is a single root directory key communicated to the client device from the central server device at a client online session start-up. This root directory key is the encoded value of the root content file (“root table-of-content file”) which contains the encoded values/keys of all subdirectory content files (“leaf table-of-content files”). Those subdirectory content tiles in turn contain the encoded values (hash values) of single data files. The virtual file system downloads subdirectory content files on demand and caches them both in RAM and in the local file system cache assigned to each of the client devices.

If a data file is requested by the file system, first a check is performed whether the associated encoded value has already been loaded from the root content file of the subdirectory where the data file is located. if not, the root content file is loaded into RAM through a normal file operation (which means, if the root content file is in the local file system cache, it will be loaded from the cache, otherwise an GET request will be performed). The required encoded value for loading the subdirectory content file (“leaf table-of-content files”) is in turn looked up in the root content file (“root table-of-content file”) which has been loaded at client start-up.

In a preferred embodiment, there is only a single type of HTTP requests issued by the HTTP virtual file system: HTTP GET, which fetches complete, static asset data files from the server. To make sure that an up-to-date version of a data file is downloaded when using a CDN (“Content Delivery Network”), the encoded value (checksum) of the data file is appended to the URL in a_cv tag appended to the file URL. This will cause a cache-miss and round-trip to the CDN origin server if the CDN proxy only has an outdated version of the same file (or doesn't have the data file yet at all).

The basic HTTP protocol doesn't allow listing the content of a directory, and requires an expensive server roundtrip to check whether a data file exists on the server. Both checking for the existence of a data file and listing the content of a directory are commonly used standard file system operations. The virtual file system proposed herein offers these operations by using the information from content tiles (subdirectory content files, root directory file) generated at build time. If a file doesn't exist in content file, it won't exist on the server as well, and listing the content of a directory simply means listing the content of a content file.

There may be asynchronous, parallel file operations. A single HTTP connection works serially, before a new HTTP request can be issued, the previous request must have finished. This simple single-connection-scenario has two main drawbacks:High latency can be a serious issue for file throughput, in a high latency scenario, the connection may sit idle waiting for responses for a longer time than actually transferring data.Large, low-priority I/O requests block small, high-priority I/O requests.

The virtual file system proposed implements a “massively multi-threaded” architecture to circumvent both problems. Instead of one HTTP request at a time, many requests can be “in flight” by distributing I/O requests across several threads, each managing its own HTTP connection. The actual number of parallel connections is tweakable.

In high-latency scenarios, this reduces the “average latency” per I/O request since a number of I/O request will wait for the response in parallel.

Traditionally, an I/O request for a data file is handled through the standardized open/read/write/close paradigm. The HTTP protocol hadn't been designed with this paradigm in mind, making it difficult to implement some common I/O concepts over HTTP in existing game engines. The virtual file system proposed herein provides the following: replacing traditional file I/O with a highly efficient, fully transparent implementation which works over HTTP and standard HTTP servers to a point where the online client can switch between HTTP I/O and “traditional” disk-based I/O without changing a single line of code.

The features disclosed in this specification, the figures and/or the claims may be material for the realization of the invention in its various embodiments, taken in isolation or in various combinations thereof.