You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At some point we will want to verify and store replays sent by servers and then place those runs into their respective *Records table.
How replays will be encoded, or scanned, is not decided yet. We could either implement it as part of the API, which would mean that part of its code would be closed-source. We could solve this by creating a separate, private, repository just for the Anti-Cheat, and include it as a git dependency in cargo. We would then also need a feature flag to disable that dependency and replace its code with dummy implementations accordingly. It sounds more complex than it is, but it would certainly add maintenance overhead to the API.
The alternative is that it's an entirely different service that the API communicates with. It could run independently, be written in another language, etc. This would increase the overall complexity of the system as we would have to account for the replay service being unavailable.
As for storage, we probably want to store them on an S3 Bucket.
The text was updated successfully, but these errors were encountered:
perhaps the API-side anticheat could be a dynamic library (i am most comfortable in C) aka a .dll or .so. i stay far away from anything related to internet stuff though, so idk if that's how it works xd.
It can be a dynamic library and that's one of the two options I had in mind.
The other possibility would be to make it a Rust library and just add it as a Git dependency (private repo).
Either way we will have to use conditional compilation to make the whole thing work if someone doesn't have access to the Anti-Cheat, but that shouldn't be a big deal.
At some point we will want to verify and store replays sent by servers and then place those runs into their respective
*Records
table.How replays will be encoded, or scanned, is not decided yet. We could either implement it as part of the API, which would mean that part of its code would be closed-source. We could solve this by creating a separate, private, repository just for the Anti-Cheat, and include it as a git dependency in cargo. We would then also need a feature flag to disable that dependency and replace its code with dummy implementations accordingly. It sounds more complex than it is, but it would certainly add maintenance overhead to the API.
The alternative is that it's an entirely different service that the API communicates with. It could run independently, be written in another language, etc. This would increase the overall complexity of the system as we would have to account for the replay service being unavailable.
As for storage, we probably want to store them on an S3 Bucket.
The text was updated successfully, but these errors were encountered: