HTML and CSS Reference
In-Depth Information
As a model for game asset hosting, CDNs can effectively be configured to cache requests made for certain assets
server-side, with a given set of request headers to edge locations around the world, which are closer to the players.
The advantage is you don't need to distribute your assets to these locations; that task is usually handled by the CDN.
Another advantage to CDNs is that they can help provide geolocated DNS lookups. If you request an asset from
cdn.
company.com
,
some CDN services will use Anycast to connect you to the host that is identified as being closest to the
machine that made the request. This is usually managed by the provider's DNS service and the route with the lowest
latency may not always be the geographically closest. This allows all requests for an asset to be made to a single URL,
but then handled by different servers. It is worth noting that the behaviours of CDNs in terms of configuration differ
between providers, so this is just one example of how a CDN can be used.
Imagine, similar to the local server approach, which you are able to set the cache time to be a long period of
time for assets that you consider static and are rarely modified. When you first upload the asset to your server and
request it via the CDN, which is configured to respect the cache times of the asset in the same way the client would,
the CDN edge locations make a request for the file and from that point onwards any identical requests (with the
same request headers) will be served from the CDN and not from your asset server. Your server should now have a
manageable number of requests from the CDN edge locations and the actual players will only be loading assets from
edge locations with the lowest latency for them. If you want to force the CDNs to re-request the asset, you would need
a different type of request to be made or the length of cache time to be smaller. By hashing the files as described in the
mapping table section, a new hash will indicate a change of file and hence there is no need to update the CDN edge
locations. This assumes that the cost of storage for more data is low, but the cost to invalidate the cache and ask the
CDN to re-request the files is high.
To replace an existing file with a modified version, a unique id is generated and the new file is uploaded with the
id in the URL. The mapping file is also modified to include a reference to the id and uploaded. Unlike the static asset,
the mapping table has a shorter cache time before the CDN will re-request it from the game asset server. This allows
it to quickly propagate to each of the edge locations when clients request it. Once a client receives a new mapping
table, it will request the new asset from the nearest edge location, which will in turn request it from the game asset
server. This will need to happen for all edge locations. Once the new asset has been requested and propagated to all
edge locations, then all players can access the new asset. The time it takes for this to happen is effectively the “server-
side cache” length (i.e., the time from having uploaded the new asset and mapping table to the time when all users
can get the new version of the game asset). Because the old mapping table can still be accessed, both versions can be
requested. This has the advantage that it can be used to stagger the roll-out of a new update, by selecting to only serve
the new mapping table to a percentage of clients. In this scenario, some players will be given the new game with new
assets and some the old game with old assets.
Figure
2-5
shows an example scenario in which clients are requesting different mapping tables and assets from
a range of edge locations. It also shows the data that needs to be requested by the clients and the edge locations to
satisfy the requirements of the game. Client 1 wants to load version 2 of the game. From the mapping table m2, it
requires the group of assets known as a2 and aC. Since the client has already played version 1 of the game, it has
both a1 and aC in its cache. This means that it will only need to request a2 in order to play the game. It does so by
requesting the assets from Edge Location 1. That server has already downloaded the assets from the Host Server, and
therefore no additional requests to the host are required. Client 2 wants to load version 1 of the game. From mapping
table m1, it requires the group of assets known as a1 and aC. Since the client has not played the game it will have to
request both a1 and aC. It requests these from its preferred server, Edge Location 1. Again, the server already has a1
and aC cached, so it does not need to make any requests to the Host Server. Client 3 wants to load version 2 of the
game. From mapping table m2, it requires a2 and aC, which it must request because there are no cached assets. This
time, the preferred server is Edge Location 2. This server does have the common assets aC, but does not have a2. The
server can quickly respond with aC, but it needs to request a2 from the Host Server. This will only happen once for a
single client per edge location. After that, all other clients requesting from that server will be served with the cached
assets. This simplified example shows how shared content and the distribution among edge locations can reduce the
number of requests when serving multiple versions of a game, resulting in less required data transfer.
