Since then I've started to check the sums after downloading, just to be sure.
I wish every binary format would include a hash of the content.
Also this is something that can be in HTTP – it's kind of silly I need to manually download a separate sum file and run a command to check it. Servers can send a header, and user agents can verify the hash. I don't know why this isn't part of HTTP already, because it seems pretty useful to me.
It could probably be improved, but HTTP does support this already:
And since this proposed protocol operates over TCP, there's relatively little that can be done to achieve the performance goals vs what you can already do with HTTP.
And because "everything" already speaks HTTP, you can get pretty close to max performance just via client side intelligence talking to existing backend infrastructure, so there's no need to try to get people to adopt a new protocol. Modern CDNs have gobs of endpoints worldwide.
A relatively simple client can do enough range requests in parallel to saturate typical last-mile pipes, and more intelligent clients can do fancy things to get max performance.
For example, some clients will do range requests against all IPs returned from DNS resolution to detect which servers are "closer" or less busy, and for really large downloads, they'll repeat this throughout the download to constantly meander towards the fastest sources. Another variation (which might be less common these days), is if the initial response is a redirect, it may imply redirects are being used as a load distribution mechanism, so again clients can ask again throughout the download to see if a different set of servers gets offered up as potentially faster sources. Again, all of this works today with plain old HTTP.
Actually, this is generally untrue. Companies BELIEVE this but often times, these players are a vocal minority put on pedastal and they often end up making the game worse for the general player base.
It's not uncommon now for popular professional streamers to get early access to new features/modes because the game companies know that those players can help build or retain the player base.
This is what every dev who can't be bothered to implement relevancy filters says when their server broadcasts the locations of every hidden player to every other player every tick and wallhacks drop a week later
Exactly what can't be fixed server side? Are you just talking about aimbots and other situations where script kiddies can trivially author bots that generate optimal inputs? Because at a certain point that's more a problem with shitty, boring game design that got stale 20 years ago; if the top of your game's execution ceiling is "can the player click on heads perfectly" you have bigger problems
But taking a step back, for fast games (like an FPS), the latency requirements drive you to send semi-secret info to the client (like the positions of other players), and so that's where things start to break down. But the traffic in the other direction is a problem too, as you have all of the scenarios in which the messages to the server (e.g. aim info, timing of weapon of firing) can be spoofed or engineered.
The motivation for the client-side anti-cheat systems is to extend as far as possible the envelope of what is considered trustworthy - i.e. if they can't solve the latency problem, then they try to make the client more trusted.
It's impossible to completely solve the problem, so it's about finding a solution that solves as much of the problem as possible. Unfortunately the main thing going for kernel anti-cheat is that most users don't care that they have to let someone root their machines to play a game, though the tide would likely turn if there were a high publicity exploit.
Thought: If they expect a console level of lockdown, why do they bother writing for the PC? If I wanted a $game_console, I’d buy the console.
These kinds of sweeping comments are as frequent as they are tiring. There are other comments like yours in this thread and yours is currently at the top. It has nothing to do with a lack of curiosity, you’re simply seeing the contrarian dynamic at play.
- you are a tiny minority and not the target customer
- online multiplayer games are an absurdly big business (i.e. there are huge incentives here)
- no, you can't completely solve this server side
- elite players are insanely good - they are by definition outliers, so looking for statistical outliers is not in itself a solution
- game companies are highly incentivized to work with (or at least not antagonize) the elite players (so just throwing them in matches with cheaters is not a solution)
- the stakes are high both for the devs and their users, so "pretty good" anti-cheat is usually insufficient
You can sum things up by saying that kernel-level anti-cheat DRM is the worst solution, except for all of the other solutions.I hope to see more discussion on possible solutions and tradeoffs - this is a challenging technical problem whose solution (if there is one) is fairly valuable.
[edit: hopefully fixed the tone, per feedback]
As far as the results go, though, I don't see any realistic scenario where this is a net win vs a symlink. :)