[janus]

[Hajo]

I can imagine two approaches:

1) A main loop, polling all clients in round-robin fashion
2) A process or thread for each client

Solution (1) seems to be easier, but maybe can't keep the near-realtime requirements and I'm not sure if it scales well, if there are more than a few dozen players to keep track of?

Solution (2) will have all the problems of inter-process communictaion and/or thread synchronization.

So far my ideas. How is it done in real life :)

Edit: Currently I don't have serious plans. I'm just asking to learn. I have a slight idea of a building a multiplayer game world, but I'm not sure if it's better to expand H-World with networking or expand a existing open source MUD/MOG with the features that I put into H-World and don't want to miss.

Does/will ManaWorld allow users to expand the game world with new areas, like some MUDs do?

[Ren]

[Verious]

[LeoDraco]

[biggerUniverse]

http://jerome.biggeruniverse.com :)
_________________
We are on the outer reaches of someone else's universe.

[Hajo]

BiggerUniverse, thanks for the link, but unfortunately H-World is C++ (I wanted a change from my job to my private projects) and I don't think a C++/Java hybrid would be a good idea on the long run. Yet, seeing the Jerome project, I very much regret to have made my choice against Java :(

Verious, thank you for the links. The explanations are very good! I knew about thread pools in Java, but since I never used Threads in C++ so far, the solution didn't come to my mind.

I didn't know about IO Completion Ports. The article is specific for Windows. H-World is dual-platform, Linux and Windows. Is there a similar API available for Linux or are there ways to emulate IO Completion Ports with plain sockets?

Thanks for your help!

[Bjorn]

I will try to answer a few things quickly, because I'm in a bit of a hurry. At the moment we're putting down the overall server design and the main loop of the server, and we're only moderately worrying about how to handle 1000 connected clients at the same time. The design should be flexible enough to be changed as needed later.

Also, because we're a free project with no money for any big servers (we don't want to depend on donations either), we're aiming for about 1000 players per server (possibly even less) and servers with a 1 Mbps internet connection (so many people would be able to host a server).

For more information, you could look here:

http://themanaworld.sourceforge.net/wiki/?ServerDevelopment

Just note that we haven't actually started to write any code yet.

[Hajo]

Actually the question where to host the game worries me most. Indeed it is the reason why I never tried to make a MOG so far.

Hosting is expensive and my own internet connection gets shut down every 24 hours and a new IP address is assigned after opening it again. (They do it just to prevent offering services this way, it's done on purpose).

I assume even 1000 users are a dream for my project, I rather think in magnitudes of a few dozen to a few hundred if I'm lucky.

[biggerUniverse]

If you aren't expecting many users, then a single-threaded round-robin approach can work. Look at any of the MUDs (Aber, Diku, etc.) and see how they are handling it. With either thread pools or single threaded, of utmost importance is how you implement your messaging subsystem. I.e., how you handle queuing, how different message types are handled, and how they are moved around.
_________________
We are on the outer reaches of someone else's universe.

[Hajo]

A message queing system ... I don't know how to fit it to my current idea of the architecture.

ATM my client uses an RPC (remote procedure call) style communication. E.g. the client asks the server to send map data for a certain cell of the world and in response the client will receive this data.

Maybe this is a bad idea?

A message queuing system will detach the networking layer and the server code. The server reads the message from the clients socket, and put it into the queue. Later the message will be processed. How does the result find the path to the correct client?

Maybe I should move away from the RPC style to a messaging style communication? Use a free flow of messages in both directions? Looks like anarchy, and I'm afraid that it adds quite some complexity in handling the server responses on the client side?

You see, I'm the 100% newbie in this area. I appreciate all your input very much!

[tcaudilllg]

I think the queue idea is the best of all possible solutions, given what we seem to know about them.

With a queue you can get info from everybody, and update the system at set intervals. It works out in "realtime" because everyone is working on the same set of information, so no one notices it's a "fragmented" timeline they are playing on.

I had an idea to use cookies to communicate with a CGI script, and to exchange data between clients that way. The cookie is written to an "action" file, so to speak, with the actions of each player loaded in their turn. Each player would update the action file with their action once an interval. (say, every 10th of a second) The CGI script would, at the beginning of each interval, load the action file and make the changes described in it happen on the client. In this way, all the clients do the work of running the game, and the CGI script is left with the work of managing the record of their respective actions, so that the clients can come to it to learn what the other clients have done.

To do this effectively, one would need to exacerbate the length of a CGI script. Most servers have a timeout period enforced over large script loops, and will cut them off. This tactic can be mediated by using the sleep statement to pause the script, but even this only works for a few minutes, after which the local internet backbone will clip the transmission. Reloading the CGI before then, say every two minutes or so, could work I think. I made some test programs to learn all of this, and put them on Tripod for testing, but I don't think even they function anymore, so maybe web administrators have become wise to the "sleeping loop" strategy I described. They don't really have a reason to stop it, because it's not a big bandwidth hog at all, really, and it would actually bring MORE traffic to their servers and more ad revenue with it, but go figure....

[biggerUniverse]

[Hajo]

@Biggeruniverse

Yesterday I discussed this problem with a colleague. We discussed pros and cons of RPC and message queuing implementations. The most flexible system seems to be message queuing, but it's also the most complex.

We brought up the idea of two queues:_ a queue client->server and a queue server->client

Messages contain a action to perform and parameters/data needed to peform this action. So a message from client to server which as RPC would be waiting for a result, causes the server to send back a message with an action that produces this result on the client.

At the moment I have no sound idea if this way of detached asynchroneous action handling works well, but I think since the sequence of messages is kept, it should.

Currently I feel seriously trapped because Java is much better in the networking support, but most of my selfmade code so far is C++. Either way I'll have to write a lot of code or port a lot of code. I don't know if I'll try it.

@LordGalbalan

I had a near-realtime system in mind. CGI and cookies don't fit well in this scenario, I think.

[tcaudilllg]

Hajo:
Well if you take out the cookies and CGI and replace them with an array hosted by the server, then I think the same could work OK, don't you think?