Server side question.

I was wondering if it would be a good idea to write the server side of a game with the following thought process:

1) Have a thread for listening for incoming connections.

2) Once we get a connection accept and start a new thread passing the file descriptor in as the parameter. At this point the player can create a new account or login to and existing one. Thread will then handle normal gameplay for that player. When player disconnects close the FD and end the thread.

3) Main thread will do the server side updating. Moving projectiles and AI controlled objects.

Is there a limit to how many threads you can have or should have? Would this be a viable design for a server / clients game? Or is there something fundamentally wrong?

So, if there are 100 players playing at a time, there would be 100 new threads? Is that really a good idea?

AFAIK, the usual way to do a client-server for a game is the client should also be able to predict the gameworld that is calculated by the server. So the projectile movement, AI, etc should also be calculated on the client to predict how the actual game world in the server will be updated. And then after the client received the server's update, it will then correct the predicted data. This way if there are different network latencies for each clients, the client's can still update the world per tick based on its own prediction.

I suggest you read:

Game Development Tutorials – Networking for Game Programmers
Game Development Tutorials – Game Physics – Networked Physcis
Unreal Networking Architecture

The players will have a copy of their own data yes. I wasn't trying to imply they would be asking for everything everytime. I was asking if it is a bad idea to give each player it's own thread to communicate in. That was in terms of if I don't and lets say we use an array to hold connections we could have players all having better conditions if they have their own threads correct or no?

OIC. I thought you are doing it by the latency judging from the 3rd point. I dunno if it is a good idea or not to have a thread for each player. But 1 thing on my mind, what about the data synchronization issues? With that many threads, how do you handle the integrity of the data if, say, 2 or more clients are accessing them at the same time? Or, if you implement locking for the thread, won't that make another cost in the whole routines? Add that with the possibility of more than 100 clients for the game.

You can try it yourself though because I haven't tried it myself. So I don't know whether my assumptions are correct or not.

Yea the data sych will be ungodly hard at least IMO - but I have an idea to fix that ever so simplisticly although probably giving us something we all hate to some point - loading. I am thinking just a small RPG I doubt I will ever get 100 people on there much less 10, but who knows. I have the ability to make maps that interlock and would only require people in each place to update with people in that place. Like say you walk into a shop I can give each player their own store instance if you want to call it that. This I belive would cut down on keeping all the threads *everywhere* syched up. Just dealing with *one* area at a time could perhaps make the data safer since we don't have 500 people adding projectiles or what have you to arrays or linked lists. I was just wondering if it would be more efficent in the long run I have written a simple server that uses threads for each connection. I suppose I could run 500 loopback telnet sessions and see what happens as well... Would bet my 5 minute no-input timeout would start killing connections partway through that though lol.

The client usually does the bulk of the work, server syncs up the clients and adds in new players, manages the lobby, etc. I have heard about a few recent games that use other systems on the network to process various objects so the network load is shared. Obviously this creates problems when a client is dropped but in theory it sounds like a good idea.

Right now I have a small socket class that helps me control the sockets without thinking much of the background. I have multithreaded sadly with _beginthread and not _beginthreadex as I was having trouble getting code to compile. Just a basic idea of how this is working at the moment probably won't stay this way. Keep in mind I am not updating anything right now it pretty much just shows me whats being thrown at the server(I am just using telnet to toss stuff). I remeber back in oh '05 or so I wrote a RPG online where you could walk around and kill stuff loot equipment and goto town. Talk to other players etc the graphics were horrible, but ok for a first shot at graphics... Anyhow I am taking a RPG I have been coding for a couple years in my down time and trying to convert it to online.

Code:

---

#include <winsock2.h>
#include <iostream>
#include <stdio.h>
#include <conio.h>
#include <windows.h>
#include <process.h>

using namespace std;
#include "mysocket.h"

const int MAXCONN = 1000;
const int TIMEOUT = 300000;
mysocket* connections[MAXCONN];
bool inuse[MAXCONN] = {false};

int  Find_Open_Slot(int fd);
void Handle_New_Connection(void *);

int main(void)
{
    mysocket test;
    test.Startup();
    test.Listen(27115);
    while(!kbhit())
    {
        if(test.HasData())
        {
            _beginthread(Handle_New_Connection, 0,(void *)Find_Open_Slot(test.Accept()));
        }
    }
    test.Shutdown();
    return 0;
}
int Find_Open_Slot(int fd)
{
    cout<<"Searching for space for new connection..."<<endl;
    for(int z = 0;z < MAXCONN;z++)
    {
        if(!inuse[z])
        {
            cout<<"Allocated to slot "<<z<<endl;
            connections[z] = new mysocket(fd);
            inuse[z] = true;
            return z;
        }
    }
    cout<<"Space not found server is at capacity."<<endl;
    return -1;
}

void Handle_New_Connection(void *arg)
{
    int LOCAL_TIME = clock();
    bool die = false;
    cout<<"Handling new connection at: "<<(int)arg<<endl;
    while(!die && (clock() - LOCAL_TIME) < TIMEOUT)
    {
        if(connections[(int)arg]->HasData())
        {
            LOCAL_TIME = clock();
            char *text;
            text = connections[(int)arg]->Recv();
            if(text[0] == 0){die = true;}
            //DO SOMETHING WITH DATA HERE!
            delete text;
        }
    }
    if((clock() - LOCAL_TIME) >= TIMEOUT)
    {
        cout<<connections[(int)arg]->Send("You have been dropped!")<<endl;
        cout<<"dropping player on "<<(int)arg<<" due to no input for 5 minutes."<<endl;
    }
    //free up the player's spot for the new player
    delete connections[(int)arg];
    inuse[(int)arg] = false;
    //kill the thread
    _endthread();
}

---

Bubba I wanted to ask... The server does all the calculations correct like for loot generation that MUST be done on the server the client has no way to guess what is going to be generated and frankly I won't even know as I plan to use loot levels and random rolls to give loot. Damage would have to be calculated as it is also random. AI movement to me is random unless it is hostile to the player or another mob. All the graphics falls solely on the client allowing for customization of the graphics settings. I am unsure how you would split the workload with calculations the players should have no chance to interfer with like loot generation or damage calculations. Is my approach sound or is this supposed to be shared somehow?


edit: May have answered my own question a little bit once I get to the point where I start enabling vision lines the player could calculate a mask of what it can see and mask it with the incoming update from the server...