Best way to handle networking.

Hey guys, I’m here with a simple question about networking (no I’m not going to ask how to get it working haha) Basically my question is about handling a ton of people on a server at once (think MMO) and have the server running efficiently with no data loss.

Here’s the way I see a MMO work in a perfect world (well not even an MMO, just thin a MO, not massive)

Client -> Server -> Database -> Server -> Client

The problem with that is going to be (i would imagine) too much of a load on the server to run database queries that often. Maybe a more logical solution would be something along the lines of

Client -> Server -> Client

Storing temporary data in the server application and every minute or so run a query to inject the data into a database. The problems with that approach will be if the server goes down you’ll lose everyone’s last minute or so of activity seeing as the server is set of a specific inject timer.

Which brings me to my final approach, same as the last one it would be a simple

Client -> Server -> Client

Except the server’s storing a client inject timer; so at a specific time (different for each client) it’ll inject tiny bits of data into the database (taking a server load off injecting massive amounts of data at once). Also the benefits of that would be the ability to force a client inject upon logoff, so there would be minimal room for dataloss.

So my question now is, am I correct with my hypothesis for these approaches?

Which is more CPU intensive for a server if we’re, say, injecting 1 meg of data into a database:

1 Query injecting 1 Megabyte of information into a database,
or 100 Queries each injecting 10kb into a database?

Thanks for your time :slight_smile: I’d also appreciate an explanation to your answers, so don’t just say “this method is better”. Rather, say “this method is better, BECAUSE”. I don’t want to be told what is what, I want to be told why. I’m here to learn :slight_smile:

Look forward to hearing some responses!

I presume injecting it multiple times is slower - you’re calling. File handle (or the like for databases) and then copying, and whilst copying a file once may take time copying the data, you’re not having to access the database as often.

So you think it’d be best to have the server on a timer to inject everyone’s data all at once?

I found this page which lists some advantages and disadvantages:

Personally, I just keep everything in memory with occasional file dumps (usually every player gets their own file, and one big one for the server state) IMHO I think it would be easier to build your game, refactoring later when you actually know what things are slowing it down.

IMHO I think it would be easier to build your game, refactoring later when you actually know what things are slowing it down.

So very true. Unfortunately I’m not creating an MMO anytime in my near future. I’m simply studying networking for educational purposes :slight_smile: I like challenging my programming skills, so as a exercise I was going to write a simple server application. I was simple wondering what the proper way of going about a server was.

Another question. You said every player gets their own file. That got me thinking; What would be better to use? Files or a database like MySQL? MySQL would be more secure, but which is more robust?

Well, It’s always tricky:
I prefer MySQL ->it’s ordered and logic, not like writing and reading lines from a file. Plus, you have to call all the functions just to open it!
On the other hand, adding mysql is another dependancy for the end user,plus i don’t know how python integrates with MySQL.

Could you explain what you meant by “adding mysql is another dependancy for the end user”?

I’m talking about a remote server, MySQL would be installed on that server, therefore stashing all the data on the remote server. Like most online games NOTHING will be stored on the end users machine (otherwise you’re open to a whole world of game hacking).

EDIT: Interacting with python isn’t necessary, seeing as the server will most likely be written in C. MySQL would be called via command line. The client would be written in python however to interact with blender, but that would never have to directly interact with MySQL. It would have to make it through the server first.

I think I came up with a good method for efficient networking :slight_smile: The way I’m handling it right now (with no problems as of yet) is like:

Client -> Virtual Client -> Server -> Database

Basically the way I have it working is the client (you) sends messages to the “Virtual Client” which is basically a “command bot” that translates the commands sent and either handles them himself, or passes them to the server. Each client has their own virtual client, which stores all the temporary data before getting processed to the server. So every so often the virtual client adds all the client’s temporary data to the server’s MySQL queue. Then at an appropriate time the server performs a MySQL dump.

The reason I went about doing it this way rather than the aforementioned methods was the fact that if each client is talking directly to the server, what happens when two people try to MySQL dump at the same time? The server will get confused and there will be dataloss. So that’s why I came up with the idea of having virtual clients and a MySQL server queue.

Not sure how this would perform with a ridiculous amount of players. But in a test with 10 players in a lobby, there was no lag :smiley:

Well, that sounds like a cool idea!
However, could you not add all data to a queue, then add the data from the start of the queue to the database?

data = received from client



data= queue[0]
mySQL insert data[0] into table where user = data[1]

I’m not sure I understood you? That is what I’m doing.

Instead of having virtual clients, have all clients connect to the single server instance, then queue the data, dealing with the data separately.

While I could do that, I’d rather not constantly be interacting with the server. The server’s main purpose is going to be to receive data and put it in the database (and of course… be a server). Virtual clients keeps from having anything conflict with each other, plus if anything goes wrong and the client crashes or hijacks the “server”… the server is actually untouched because it only messed up/crashed the virtual server. Just another way to protect other clients from being the victims of a crash.