I am making a simple MMO backend with Django as a personal/portfolio project.
(I am not actually making an mmo game)
You can find the project here
So I have some questions for the architecture because I designed it
1. Architecture
1.1 Terminology
AuthServer= Web Server responsible for the authentication
UniverseServer= Web Server responsible for the persistent storage of the game (Couldn't find a better naming)
MatchmakingServer= Web Server that acts as intermediary between the client and the GameServerManager
GameServerManager= A cluster manager responsible for starting/stoping GameServerInstances
GameServerInstance= An instance of the game server
PlayerClient= The game client of the player
1.2 Flow
1.2.1 Authentication
PlayerClient logins to AuthServer to obtain an AuthToken at /api/auth/login/
1.2.2 Retrieving Player Data
PlayerClient requests all the needed data from the UniverseServer at /api/universe/user/{...} (example: the characters list)
1.2.3 Connecting To A Game Server
PlayerClient requests an available game server from the MatchmakingServer with some parameters
The MatchmakingServer checks if there is an available GameServerInstance on the database with these parameters
If there is an available GameServerInstance, the MatchmakingServer responds to the PlayerClient with the IP and the Port of the GameServerInstance, else it is gonna send a request to the GameServerManagerto spawn one
When the MatchmakingServer would request the GameServerManager to spawn an instance it would pass a ServerAuthToken so that the GameServerInstance can make authorized requests to /api/universe/server/{...}/ to update any value (example: the experience of a character)
On the Django project I am implementing AuthServer, UniverseServer, MatchmakingServer as separate apps to stay as modular as possible.
First of all I would love from an experienced in this field to review the whole architecture.
And the questions:
Does this architecture makes sense? What could I change to improve (even for naming for a more standard namings/functionality/etc...)
What tools can be used as GameServerManager. Can kubernetes/agones do that? Does AWS or CloudOcean have anything for this?
I am making this project as a portfolio but does this architecture/stack have the capabilities to go to production for even an mmo with a low playerbase like ROTMG?
How could this be scaled? Separate the apps to different projects and host everything individually? Use load balancers? Use proxies?
Is this considered cloud architecture or cloud orchestration or something else?
Every advice is welcome
From the questions you can understand that I have minimal knowledge on this field so please be as detailed as possible (or/and provide resources to read more)
Thanks for your time :)
Related
I am developing a multiplayer game (client-server model) and I am stuck when it comes to scaling its servers.
I understand that most games never even reach 10 000+ players, and I don't think mine will either.
Though if I would be very lucky to get that I want to develop the servers so they cannot become a huge obsticle later.
I have searched a lot for a solution to my problem on the internet, checking GDC talks about it and checking other posts on this website, but none of them seems to solve my specific problem.
My current setup is below and all servers are written in C++ using ENet as my network library.
Game server
This server handles the actual gameplay of the game and requires quite a lot of CPU and packages being sent between the server and its connected clients.
But this dedicated server is hosted by the players themselves, so I don't have to think about scaling it at all.
Lobby server
This server handles the server list, containing all servers currently up.
All game servers are sending a UDP package to this server every 5 seconds to say they are still alive.
This is so the lobby server can keep an updated list of all servers currently online.
All clients are sending a UDP package to this server when they want to fetch all servers (which is only in the server
list screen), and the lobby server sends back a list of all servers.
This does not happen that often and the lobby server is limited to send 4 servers per second to a client (and not a huge package containing all servers).
Login server
This server handles creating accounts, lost password, logins, friends and their current game status,
private messages to other logged in players and player profiles that specifies what in-game items they have.
All clients are sending a UDP package to this server every 5 seconds to say they are still alive, while also
sending what game they are currently in. The server then sends back their friend lists online/offline/in-game statuses.
This is so their friends can keep an updated list of which friend is online/offline/in-game.
It sends messages only with player actions otherwise, like creating an account, logging in, changing/resetting password,
adding/removing/ignoring a friend, private messages to friends, etc.
My questions
What I am worried about is that my lobby and login server might not be scalable and that they would have too much traffic on them.
1. Could they in theory be hosted on just a single computer? Or would it be too much traffic for 10 000+ players?
2. If they can be hosted on a single computer, will the servers still not have issues for people that live far away?
Would it be better to have the lobby and login servers per region of the world in that case?
The bad thing about that is that the players would not be able to see servers in the US if they live in Europe, and that their account and items would not exist on the other servers.
3. Might be far-fetched, but if I would rewrite both servers to instead be on a website with a database and make the client/game server do
web requests instead (such as HTTPS or calling a php with specific headers),
would it help in solving my problems somehow?
All your problems and questions are solved by serverless cloud based solution AWS Lambda e.g. or similar. In this case the scalability is not your problem. Just develop the logic. This will save you much time.
If you would like to make servers as single app hosted by your own server. Consider using something like e.g. Go instead of C++. It's designed exactly for these purposes. I mean highly loaded web/network services.
Well, this is c++ and i code in java, but maybe the logic is useful for you any way so i will tell you how i end up implementing something similar but in a casino.
In my case I have 2 diferrent sockets in the same server program, one of the sockets is TCP and it handles all logins, registers and payments, while the second socket is UDP and it handle the actual game multiple payers are playing, then you could group internally all those UDP connection in groups (probably arrays of sockets) to generate those lobbies. Doing that all your server is just one class that could run in a single pc using 2 ports (one for each socket) However this do not solve the problem of the ping for people who live far away.
If ping is a problem (not my case in a casino) you could probably host your server region base but removing the login, registration and paymets of your server and replace it for a connection to a central server (this central server should be TCP and you could also implement a https socket to also allow your webpage to connect to this server and create accounts or pay you directly from the browser)
sorry to mess your life even more, but i hope it helps
I know the question I am going to ask is a bit duplicate. But, I am still asking as I want to know the latest technologies and I am a bit lost after researching for a few hours.
I have a Raspberry Pi logging real-time temperature and humidity. Now, I am writing a flask app to push these data to clients who (subject to rights) will be able to observe continuously without refreshing the dashboard/page.
What will be the best option to make an efficient system, keeping in mind that there will be multiple sensors in the future? The options I find:
Ajax
WebSocket
Framework e.g. bokeh or dash
MQTT
Please give me your opinions.
Good choice if you want to write your backend using Python is:
Server: Flask with Sokcet.IO + InfluxDB for real-time data storing
Frontend: Some JS framework or pure Js + websocket
UPD (this message is too long to post it to comments):
https://www.smashingmagazine.com/2018/02/sse-websockets-data-flow-http2/
The thing is that I'm not talking that websocket is the right solution for all possible cases/problems and should be used everywhere. Obviously it's depends on your needs and your project architecture. I think that article can help you to make a choice: if your app architecture requires full-duplex browser-server connection - you can use websocket for this and that will work for you, but if your frontend requires only one-way data send direction - from server to browser - you can use SSE, as the article says about SSE: "our main flow of data is from the server to the client and in much fewer occasions from the client to the server". To sum it up, you need to think about your application architecture and about how data needs to be sent between browser and server to choose right technology. Also, if you don't want to use neither websocket nor SSE - you can use ajax to pull data from server and that will also work for you.
Hello Stackoverflowers,
We're developing an online board-game (think online monopoly) site using Python for the backend.
We use Django for the non realtime stuff (authenticating, player profiles, ranking...). The chat server is implemented using socket.io and Tornodo. The game server part is what caused us problems.
We currently (that could change) also use Tornado and socket.io, each Tornado instance is located at a gameX.site.com address on a (maybe) different server and host several games simultaneously (much like a chat server in fact, except that messages would not go to all users but only to the ones involved in the same game).
What cause us trouble is how to we update the Django instance (game log, score, and so on) as games progress. Also we'd like to use Django for authentication as each player would ask the Django server to join the game and be given a disposable id/password couple just for it. Obviously we would have to communicate those to the game server in some way.
At first the chosen solution was to use something like Redis as a bidirectional message queue, Django would post is/password to Redis and the Tornado would then querying Redis on incoming connection. Also a Django cron would run every minute or so to deal with the waiting message. But we fear that frequently and possibly long running cron would impede the main site since the PostgreSQL database is hosted on the same server as Django (and some Game server may also run on the same machine).
We could alternatively wait for a player to request a ranking updated to process the past games results but we fear such an indefinite delay will skew the overall ranking (and experience) and would possibly cause data loss.
We could use Celery/RabbitMQ to update the Main database using Django ORM out of the Tornado processes, but would it be possible to use the same solution to communicate the temporary id/password to the game server ? It doesn't look like you can post a message to Celery and retrieve it on an other side.
Thank for your insight.
I'm building an app which upon login will connect you to certain ip addresses of which will also be running the same app.
The method of which i believe i should be using is direct tunnelling but as i say im a little new to c++, i have general coding skills, and i have sifted through a lot of forums and sites yet im still very unclear on what the best way forward is to achieve the requirement.
The reason for the connection will be to enable a secure chat, file transfer, and update software auto when connected to the program admin.
All those that have the app installed will once authorised, will be connected to admin client, then from that client all available ip's to connect to will become available to slave clients, this will increase the network size avilable to all users.
so the app needs to be able to handle ports but not via a server, instead it would be direct.
The connections also must ideally be encrypted.
Im kind of looking for what the application RetroShare does, but in text app.
(This is using C++ within Dev C++)
so just to recap, What method should i use to achieve the above?
I would take a look at SDL net to start with, its really simple to learn if you have never done any socket programming before.
for a secure connection you will probably want to start with TCP and then once you get the hang of network programming, start looking at other protocols.
Hope this helped! and good luck.
I develop industrial client/server application (C++) with strong real time requirements.
I feel it is time to change the look of the client interface - which is developed in MFC - but I am wondering which would be the right choice.
If I go for a web client is there any way to exchange data between C++ and javascript other than AJAX <-> Web service <-> COM ?
Requirements for the web client are: Quick statuses refresh, user commands, tables
My team had to make that same decision a few months ago...
The cool thing about making it a web application would be that it would be very easy to modify later on. Even the user of the interface (with a little know-how) could modify it to suit his/her needs. Custom software becomes just that much easier.
We went with a web interface and ajax seems the way to go, it was quite responsive.
On the other hand, depending on how strong your real time requirements are, it might prove difficult. We had the challenge of plotting real time data through a browser, we ended up going with a firefox plugin to draw the plot. If you're simply trying to display real time text data, it shouldn't be as big an issue.
Run some tests for your specific application and see what it looks like.
Something else to consider, if you are having a web page be an interface to your server, keep in mind you will need to figure a way to update one client when another changes the state of the server if you plan on allowing multiple interfaces to your server.
I usually build my applications 2-folded :
Have the real heavy-duty application CLI-only. The protocol used is usually text-only based, composed of requests and answers.
Wrap a GUI around as another process that talks to the CLI back-end.
The web interface is then just another GUI to wrap around. It is also much easier to wrap a REST/JSON based API on the CLI interface (just automatically translate the messages).
The debugging is also quite easy to do, since you can just dump the requests between the 2 elements and reproduce the bugs much more easily.
Write an HTTP server in your server to handle the AJAX feedback. If you don't want to serve files, create your server on a non-standard port (eg. 8081) and use a regular web server for the actual web page delivery. Now have your AJAX engine communicate with the server on the Bizarro port instead of port 80.
But it's not that hard to write the file server part, also. If you do that, you also get to generate web pages on-the-fly with your data pre-filled, if you want.
Google Desktop Search does this now. When I search my desktop for 'foobar', the URL that opens is this:
http://127.0.0.1:4664/search?q=foobar&flags=68&num=10
In this case, the 4664 is the Bizarro port. (GoogleDesktop serves all the data here; it only uses the Bizarro port to avoid conflicts with any web server I might be running.)
You may want to consider where your data lives. If your application feeds a back-end database, you could write a web app leaving your c++ code in tact -- the web application would be independent and offer up pages to web users and talk directly to the database -- In this case you have as many options, and more, as you have indicated.