Greetings, yesterday i heard of an idea of handling a MMO, that i never thought of before. I want to get your opinions on that. While discussing ways of creating the networking model for a MMO, a friend of mine suggested to use a LAMP and control all client/server communication via PHP. Data shall be exchanged in XML or a similar format. First, i thought it was a joke, but he told me that similar concepts are in use already. What do you think?

Quote:

Original post by Tomen Greetings, yesterday i heard of an idea of handling a MMO, that i never thought of before. I want to get your opinions on that. While discussing ways of creating the networking model for a MMO, a friend of mine suggested to use a LAMP and control all client/server communication via PHP. Data shall be exchanged in XML or a similar format. First, i thought it was a joke, but he told me that similar concepts are in use already. What do you think?

Who you been talking too? I've been developing on this idea =D

I think this could work based on the fact that "All DB Access Should be used as little as possible, Especially Reads!"

If you are reading from the DB EVERY round of data, you will have problems... Max Connections, DB Resources....

There would be 2 Initial Reads:
Login Authentication (so the client can login -- expected)
Inital Char Setup (loading the char from the DB -- includes building 1)
After that, you should be doing 90% updates only... (10% is still rather high)

The Server should handle the state, not the DB.... The server should dump the state, but only read on startup or if somethig is fishy....

This is all assuming:
Network Server - handles game state, connections
Web Server w/ PHP and SOAP/XML - handles ALL DB Connections

Oh, and the server, in theory, could have a seperate thread for Sending Data to the Database... Most of this you could send and forget (unless you need a check in the DB that you can't perform in the code... In that case, I'd make special calls knowing it will take some time.)

If the Web Server is ONLY used by the server (I suggest that) - Then Response time should be at a peak.

Clear as Mud?

This method has several advantages... Especially with expanding, and distributing load.

Quote:

Original post by Anonymous Poster As long as the game is not real time, this can be done. For anything that needs periodic updates over once a minute, using the lamp stack is hard. Processing http queries with higher frequencies will likely overload the server because of the overhead. For turn based games or games with an update speed of 1 frame per minute the lamp stack could work. The problem is simple: If you have to send movement data to a 100 users 20 times a second, that would mean 20000 hits per second on your web server and database. Few servers can handle it without problems. On the other side, a simple udp based implementation will only send 20000 udp packets with binary data and that is much less work to do. However, some mmo-s do use the web for certain things like on the fly content downloads (models and textures) or simple web shops. A game called 'There' runs most of its user interface on web pages with flash, the chat with tcp and handles the 3d part (movement info) with udp packets. Viktor

Your forgetting... Clustering... Add 100 Servers if needed...(The prettyness of HTTP and even for SQL =)

However - I do not suggest all Clients Talk directly to the WebServer as this will increase logic required and PHP is by no means the fastest language.

I suggest using this as the DataBase Connectivity Layer for peak effectiveness. (And make it internal only as well)

Use some External Server for the External Users and Content Downloads.

[Edited by - micah_death on May 3, 2006 9:48:38 AM]