Hajo
Demon Hunter
Joined: 30 Sep 2003
Posts: 779
Location: Between chair and keyboard.
|
 Posted: Mon Jul 30, 2007 1:25 pm Post subject: |
[quote] |
|
Heya Bjørn,
thanks for your answer. It gives an idea for what to look out when designing communication and a server. I've just been implementing some throttling of incoming packets per client, that will keep an limit on denial of service attacks, also would mend the bow problem a bit, but not solve it. It also allows to detect clients that send packets faster than expected and if this state persists can be used to disconnect them.
Once you have your own server code you'll be able to fix such problem easily, unless you inherited weaknesses of the Ragnarok protocol with your own server, since your clients were made with eAthena in mind. A curious question: Why did you go for eAthena in first place? To me it seems the server is the simpler side of the two.
| Bjørn wrote: |
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.
|
You've got that free with the Ragnarok/eAthena design ;) Is login really such a load-producing activity? I'd assume that logins are infrequent actions compared to others and do not produce much load? Chat can generate a lot of bandwidth (particularly group/guild chat) so I assume the split-off of a chatr server is a good idea. Do you have some numbers to see how the load distributes among the servers?
You copied a design of a professional game there, so you most likely copied some professional ideas ;)
| Bjørn wrote: |
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.
|
"Divide et impera" as the romans said ;) I'm going to try this too, it's a pretty straightforward solution to load balancing if the project ever needs a clustered server environment and one has the resources to set up such o.o
| Bjørn wrote: |
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. [...] For the game servers it will mean that they should be able to dynamically change the part of the world that they manage. |
It also depends how stateful your maps are. You'd need to have maps either kept on two servers so that if one fails the other has the most current state, or you need to write them to persistent storage frequently so that another server can take over a map on a crash of the former map server. This isn't easy. To call a map crashed, inform the players and restart the map from scratch on a different server might be good enough, and avoids this problems?
@mu_ds:
I hope to be able to build a presentable release later this week. I wanted to do that yesterday, but then got stuck in some other online game, rather than working on my own ;) I'll post an announcement here once it's out.
Current state:
- Three maps to explore, none of them really finished, though.
- Some example items to display graphical effects of wearing them.
- One map has some kind of beings that will leave random items if you run into them. They respawn on a new random location.
- These beings have some simple animation to showcase the animation feature.
- Chat (local chat and long-distance IM like messaging) works.
- And a yet unknown number of bugs to find.
If it matters, it's coded in Java. Just because this seemed easiest for me.
A virtual server will do for the next while. The service provider where my homepage is hosted offered an entry level virtual server for 10€ a month, when I last checked. That seems payable for me for a while.
|
|
