Today I occured interesting issue. Our server contain almost 10GB of custom addons. Due to rebuilding of file structure which I did (to reduce mounted filesystems which was nearby 400), all players had to re-download almost all data (I’ve managed to reduce amount to 141 plugins). So today all day long people had huge lags and experienced “red curse” (reeconnection). It will probably happen tomorrow also.
So when I was thinking why it happens I thought about relation of these two things. Now indeed, socket and even server bandwith suffers huge load.
What I thought of is to allow somehow to proxy the server resources from external storage-server for load-balancing purposes. That would allow to reach best latency on servers with huge data load.
Is there any possible way to implement something like that?
Uh - streaming resources are downloaded by file hash, so if the file hash was kept equivalent while reordering, these would not get redownloaded while connected to the game - and pre-downloaded resource file sets ought to be as small as possible.
More on-topic, there’s still support for fileServer in the getConfiguration method, however since manual synchronization will likely go very bad, this is not currently exposed in the actual server code.
So its actually possible to serve data through fileServer configuration? Can you give any details on it? I was considering NFS for cache sync.
Likely would need a custom server build with this changed.
Files are gathered from across the filesystem, it might be saner to set this to a persistently caching frontend proxy (forwarding all headers too, such as primarily X-CitizenFX-Token - you might be able to wing it and use CF in front of your frontend proxy with a ‘cache everything’ page rule, but doing that is technically against term 2.8 in CloudFlare’s terms of service), and set adhesive_cdnKey [secret phrase] on the server so that obfuscation is deterministic. Doing such caching, however, might break in certain ways with regards to changing resource files since the download URL - for legacy reasons - is rather like baseUrl/resourceName/resource.rpf and so on.
Indeed, that’s to be honest also good idea, proxying data “in fly”. Still it would be cool to have this:
{ “fileServer”, “https://%s/files” }
configurable to at least try to play with it 