[Hajo]

Hello,

after a long break (anyone remember H-World ?) I once more want try to make a game. More precisely I'd like to make a multiuser game this time.

I came across The Mana World and saw you run your own game server. Sooner or later I'll need my own server for my game, too, well at the point when it's playable a bit.

Since you already have experiences with The Mana World I want to ask for advice. What do I have to care about if I run a game server? I mean mostly legal stuff. Can I just put up a server and run my game there, or is this too naive? Do I need some special "user agreement" for palyers to sign, to avoid problems?

Any pointers or advice will be highly appreaciated. Thanks in advance :)

/Hajo

[Hajo]

Noone here has any experiences with running a game server?

Sorry for double posting. I'm really looking for advice. I might be able to get a share of a friends server (hosted in Canada) or get a server in Germany.

Before I decide I'd like to know what I should care about, beyond pure technical issues like bandwidth and load on the server.

[BadMrBox]

I guess Bjorn would know. He has been busy awhile now but perhaps he will swing by here soon.
_________________

[Terry]

Sorry, I would have replied but I really don't know very much about this. The Mana World project actually have a fairly active forum of their own - maybe you'll have more luck asking there?

Good to see you back, Hajo :)
_________________
http://www.distractionware.com

[Hajo]

Thank you. It's good to be back :)

Although I used The Mana World as example, I meant to ask about running a game server in general.

It'll not be another Mana World server, but my own project. Today I got confirmation that I can host it on the canadian server.

My project is too young and incomplete to make much publicity yet. This is why I didn't want to post in The Mana World forums, they are very busy and there might spawn a lot of talk about the project itself which I don't want yet.

Part of this is to ask about issues that can come up from running a game server, and what one might do to prepare for that.

So if one of you ever had his/her own game server running (any game), I'm very interested in hearing about your experiences :)

[Adam]

I've had a simple server up for my multiplayer game in very early development. Wasnt much too it apart from opening the firewall.

I think you're only really going to have issues once you get a huge ammount of people playing. And i thing you should be more worried about finishing to a decient level first before you worry about that.
_________________
https://numbatlogic.com

[Hajo]

[MDS-MU]

[Hajo]

[Verious]

[Hajo]

Thanks, these are quite helpful ideas :)

I have started to implement ban-lists by IP and by name. What I do not have yet is a client ID that is more than that. I'll think about how to create such. Now I'd like Intel's "processor number feature" back ;)

One problem is, that the clients and the server are open source, so it's easy to have a modified client log in correctly and then just run a recorded set of moves/actions against the server, all valid. The idea of denial of service attacks came up with my tries to have an automated test for the client. The test suite runs the player around, let's him sit, stand, turn, equip items, take them off, drop and pick up items, basically I tried to have each basic action in there at least once.

These are all allowed moves. But if this kind of test is run repeatedly against the server, with low delays between the moves it will cause problems. The only way to prevent this seems to be to check the number of actions from a client over a certain timeframe, and first delay responses to that client, and in a second step disconnect the client if the backlog of messages becomes too big?

Real hacks, like creating items that the player did not have before, of duping items that he has, I hope to avoid by design of the communications layer. But I assume by time I'll be taught by ingenious players about the loopholes in my design ;P

Thanks again :)

[Verious]

Never leave item creation or other sensitive actions to the client; always handle tasks that could lead to system compromise on the server. Always validate client supplied data/packets and include sanity/reality checks whenever possible. Always store game state data server-side.

Even with an open source client/server, you may want to limit the connections to the server to official clients otherwise you may find your world over-run by bots.

[Bjorn]

I haven't been here for a long time, so I only just noticed this thread. The questions you ask about denial of service attacks and abuse by players are about problems that we are facing right now, and the answer as far as I see is to continually take action as players find new ways to abuse. Of course forward thinking, like putting logic at the server and designing the protocol in a way that minimizes possiblities of abuse, gives you a good headstart.

Problems we've been having relating to this area:

* A long time ago we introduced some special skills at a test, and one of them allowed you to make better deals in shops. At the casino, however, we had used a shop for exchanging money for casino coins at equal rates. Pretty soon, somebody figured out that using the skill, he could sell coins at a higher price than they costed. This opened the way to infinite money. The problem existed for long enough that we had little choice but to cap everybody's money to a reasonable amount after deleting all characters which had obtained the skill.

* About a year ago, somebody discovered that the rate at which you fire your bow is only limited at the client and not at the server. A simple client hack (very simple, since it's open source) thus allows you to use your bow as a machine gun. We are at the moment still using eAthena, which nobody of us wants to work on, so this problem was never solved. Once we have switched to our own server, tmwserv, this problem can easily be avoided.

* Recently, somebody figured out that you could crash the client of another player by sending it a big amount of trade requests. One part of the solution would be server side, in that one player should only receive one trade request at a time, but again, nobody wants to fix eAthena. The solution will thus be to fix this problem in the next version of our client.

Our efforts towards preventing this kind of abuse are minimal at the moment, and generally have a very low priority. This will probably change as soon as we switch to using our own server. We have currently no policy against bots and no "user agreement". This is mostly so that we can forward any complaints about behaviour of other players to the garbage bin as fast as possible.

About scalability, we generally keep efficiency in mind while programming but it's very hard to say how far a server can scale. In our case, we have splitted up responsibilities among multiple servers: account server, chat server and game server. The account server handles basically only logins (and doesn't stay connected to the client afterwards) while the chat server handles chat channels, guild chat and team chat. The game server handles the logic of everything that moves in the world. Since the world consists of many maps, which are otherwise independent of each other, multiple game servers can be run that each take care of a subset of the maps that make up the world. At the moment, we run the account, chat and game servers all on the same host, but they can be distributed as necessary later.

Lastly there is the question of availability. A server is bound to go down or be unavailable some of the time, so redundancy also needs to be taken into account. We haven't given this much thought yet, but later on this will probably mean that it should be possible to run multiple account and chat servers as well, which take over the job from one another once problems occur. For the game servers it will mean that they should be able to dynamically change the part of the world that they manage.

[Verious]

Bjørn, as you mentioned, many of the issues you are facing could be eliminated at the server if you were running your own software. Have you considered writing a simple proxy server to inspect and validate incoming packets before forwarding them to the eAthena server while TMW server is in development.

The proxy server could apply sanity checks to incoming packets such rate limiting attack packets. Packets exceeding predefined rates could be discarded. The proxy could also rewrite or block specific packet types (such as those used to crash TMW client) providing an additional layer of isolation.

[MDS-MU]