What network technology would you recommend to implement a server that stores user data?

Imagine a project where all user interactions must be stored on a server. An example would be a single player chess game, where all games and moves are recorded. There will only be a few hundred concurrent users at a time that send/receive data at a maximum of two, maybe four packages per second.
There's also no need for the server to broadcast data to any other users. So the server/network load per user will be very low.

What technology would you recommend the implement the server logic?

Considering the project should launch in Q3/Q4 2020, would it be feasible to use Unity's new network architecture to implement the server? Are there any known limitations that could cause headaches later on?

Any advise on the topic is welcome,
Thank you.

 

From your description I'd say anything you're familiar with should work: php/mysql, ASP.Net/MSSQL etc.

You mean UNet? No. You need a web server, where you can send the data, which talks to a local database.

At four packet per second you might be better off aggregating a bunch of those (on the client) before calling the remote server, to reduce the traffic a bit.

 

You could consider using a Unity build as the back end, storing the data in memory, and periodically write the data to disk. In that case you'd just pick your favorite network API and file format. Even a csv file would work fine for storing the kind of data I think you're talking about.

 

You mean in total playing the title? Or in a match?

 

Thanks for your suggestions. Much appreciated!

Right now, the preferred plan for the server implementation is to run a headless Unity server build that stores the data in an SQL database. The reasons are:

1. It's easy to implement and
   
2. just one code base.
   
3. A php/asp.net/servlet container/or similar approach comes with way more workload from a development point of view.

However, how scalable do you think would a headless Unity server build approach be? Could it happen that the headless server build becomes a bottleneck, that can't be fixed by upgrading to faster hardware? From a Unity's point of view, how many concurrent users (i.e. active users at the same time) could be handled by a single server build instance? Dozens, hundreds, thousands? Are there any known limitations?

As for communication with the server, Unity's new transport layer seems to be simple to implement. Since it's the shiny new thing that comes from Unity, it looks very attractive. Mirror would be an alternative. Photon seems to be a solid approach as well. Btw, @tobiass thanks for joining in, I'll take a closer look at it.
Which of these do you think would be:

• the least amount of work to implement server and the communication with it?
• the most future proof?
• the best performing (in terms of concurrent users)?
• the easiest to scale?

Or should the whole idea of using a headless server build be discarded? If so, why?

Any advise that helps in making a wise decision is welcome.
Thank you.

 

As far as you specified, the server would not enable interaction but act as a gate to the database to store the input?
It does not have to forward input/actions from player to player in some matches or world?

I would probably recommend to use ASP or similar. While it's initially a bit more work to get used to it, the benefit is that you don't have to run a machine with Unity instance(s) on. This is potentially a lot cheaper and definitely easier to orchestrate.
Unless you need the scene, physics and or the game logic, don't run Unity on your server(s).
If you worry about scaleability, you potentially need a dev team later on, right? Then it's again easier to find a web/database developer than a Unity developer who takes care of this service.
I also don't know if C# database abstraction layers are compatible with Unity IL2CPP.

It's hard to give a better recommendation without knowing the project size and targets.