Im designing a server using sdl_net and Im thinking how many players would be reasoneable to suppport per server instance. Right now I just have one udp socket, which allows 32 channels, and each channel 32 IPs, which means 1024 players. Is this a reasonable number for a single server running in medium hardware?

What does the server *do*?

Sure you can support 1024 concurrent connections on a PII if you want (and have one that still works). Hardware alone isn't the limit on connections. It plays a part, sure but there are other questions to answer first.

Seriously, your actual number of players is limited more by what work you have to do with them than any particular limit on connections.

Think about these two questions:

1) How much data do you need to send on average to a player in a second?

2) How much time do you have to spend working things out on the server, fetching data from file/DB? Collisions? AI?

Without a lot more information about what you're trying to achieve, your question can't be sensibly answered.

Yes, there is a lot of data that in the current stage I cant figure out (processing time per player/NPC, database access time). Im looking for some reference about it, how much does it takes in the average online rpg? Should I design aiming to more than 1000 players or stay under that number?

Define 'average'! This depends entirely on what you allow a client to be aware of, the internal mechanics of the game (are there a lot of stats, or just a few?), how you generate random numbers (rand() can be slow), how efficient your encryption algorithms are (if you use them), how much stuff a client is allowed to hold in their inventory, whether you trust clients with copies of data for caching purposes etc. etc. etc.

RPG's tend to be stat-heavy, so the more RAM you have in your server for local caching of data the better, and the more RAM you have in your database server for caching there the better.

The only way you can arrive at a specific player load figure is to stress-test your architecture as your game is developed, or ensure that the architecture can scale with minimal cost to a sufficient number of servers to support the player load, and that the back-end DB can handle the demands of the servers requesting information from it.

Ok, thanks. Seems that it is too early to figure out what can I handle.

The way to approach this problem is to set a specific target, and then design/implement your game around that target. Every so often, measure that you're still supporting your goal. if not, change the design, tune the implementation, or change the goal.

Also, don't hit the database synchronously from the main server loop. Your design should be such that needed data is mostly fetched when logging in, and the database is only needed for things like trade -- and even then, you should use an asynchronous interface to the database. You should also limit the outstanding queue length for the database requests. Anything else is a sure receipe for server break-down under heavy load.

I dont know if it is a wrong approach, but I plan to keep as much as possible in memory, like npc/item data lists, and reduce database accesses.