Sign in to follow this  

Server and Client - in the same thread?

This topic is 4836 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone! I'd like to ask how most of quake-like games (max. ~ 30 players) deal with server and client running on same machine. Do they have separate threads for server and client or not? The biggest disadvantage I can see of having separate threads is need of synchronizing data access (map, models, much more...), which might be a serious problem. However having one thread for server and client makes server dependent on frames-per-second of the client's display. Thanks for hints.

Share this post


Link to post
Share on other sites
AFAIK most fps games have two options:

Dedicated server and Listen server.

Dedicated server means that the server does not take part in the game. Listen server means that the server also acts as a client.

When you set up a game as a listen server it will run in one thread. You are right, if the frame rate is low on the listen server machine, it will adversly affect the entire game for all clients. Most fps games link the physics with the rendering, i.e. you have on physics frame per render frame. But this doesn't necessarily need to be the case, you can have a game running at a constant 60 frames per second for the physics while the rendering runs at whatever the PC can manage. As long as the PC is powerfull enough to maintain the 60 fps physics updates.

Most games will allow you to run a dedicated server and client at the same time. Thus essientially running two threads, one for the server and one for the client as seperate processes. This is not a good idea however, you will get much better performance out of a listen server.

So what i'm trying to say is that there isn't really any advantage in running two threads, one for the server and one for the client.

>> having one thread for server and client makes server dependent on frames-per-second of the client's display

as i said before, this does not necessarily have to be the case.

At the end of the day, you will need a powerfull PC to run both server and client simultaneously. It is just a question of how much resources you allocate to the server and how much to the client. You can sacrafice rendering fps for the client in favour of a fast server that will not lag out other players, or you can decide to make the other clients lag a little to get a decent fps for the server.

Share this post


Link to post
Share on other sites
The internal development environment for our massively distributed platform can run one (or two!) clients, a few simulation servers, a few database servers, and some simulated/proxy hosts (web services, DNS, etc) all within the same process, for easy debugging. We do this using a single thread (and some Fibers). Even though each simulation server and client have their own copy of game state (so that we can debug distribution and co-simulation issues), we run it all in a single thread, because the locking for shared subsystems (logging, events, message queue, etc) would cost more than you'd want when running that much stuff.

Share this post


Link to post
Share on other sites
Thanks for your replies.

hplus0603,
Could you say in more details what is and what is not shared among client and server?

Also, how does your client and server running on same machine communicate? Do they exchange messages as if they were located on separate machines, that is using regular sockets? Or you made some "special case" for local player <-> server communication?

Share this post


Link to post
Share on other sites


Hi fellas,

I've been recently working on a simple pong game in openGL, and I had plans to network it using winsock. I do have some plans in the near future to network a pretty cool game for a good friend of mine. MickeyMouse raised some of the same questions that I had myself. I have a few more questions. SpaceDude, if you would be so kind as to help me out that would be great!

I had planned on having only a listening server option but using multiple threads (Apparently, it's not a good technique as you said). If you are sending & receiving data in the same thread, wouldn't you have to make sure that you are sending/receiving data constantly as to prevent a break in the other players movements/actions? It would appear to me that theoretically the clients movements would be more smooth in a multithreaded techniqued server.

As I have seen in multiple forum entries, multithreading is supposedly 'less' efficient than using a single thread. I could understand how it would be harder to develop when you're having to use mutexes plus debug. I don't know to much about multithreading but wouldn't this also depend on the operating system the game is being executed upon? Could you explain why it is less efficient if that is in fact the case. ( I realize this is a different topic )

I won't be able to respond for a few hours; I'm going out. (The response time to a question on this forum is very fast!! :) )


Thanks for your help,

GCS

Share this post


Link to post
Share on other sites
We have two implementations of our network interface: one that uses sockets, and one that runs entirely in RAM (but implements latency, drops, etc through queuing).

The in-RAM one is used for the testbed that runs all the servers in a single thread, because the servers have different "IP addresses" in that simulation -- clearly, that would be very hard to make happen if we used real sockets (though not impossible if you had enough free network adapters ... on your laptop :-)

Share this post


Link to post
Share on other sites
Hi.

There is actually a difference between multi-threading the client & server in the same process and spawning the client process and spawning the server process on the same machine.

In general, context-switch time takes a LOT longer when the OS is context-switching between two processes. Threading was introduced as a sort of "light-weight" process (I think there are more benefits than that though). Since threads all share the same memory space/locks/etc, there is less data to move around when context-switching (between threads).

That said, I think that unless your threads block, or you are running on a multi-processor, it is actually disadvantagous to write your game multi-threaded. The context-switching kills you every time.

-j

Share this post


Link to post
Share on other sites
Quote:
Original post by Queasy
Hi.

There is actually a difference between multi-threading the client & server in the same process and spawning the client process and spawning the server process on the same machine.



Excuse my ignorance, but I'm not quite understanding what you are saying. Could you eleborate a bit more?

GCS

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by gcs584
Hi fellas,

I've been recently working on a simple pong game in openGL, and I had plans to network it using winsock. I do have some plans in the near future to network a pretty cool game for a good friend of mine. MickeyMouse raised some of the same questions that I had myself. I have a few more questions. SpaceDude, if you would be so kind as to help me out that would be great!

I had planned on having only a listening server option but using multiple threads (Apparently, it's not a good technique as you said). If you are sending & receiving data in the same thread, wouldn't you have to make sure that you are sending/receiving data constantly as to prevent a break in the other players movements/actions? It would appear to me that theoretically the clients movements would be more smooth in a multithreaded techniqued server.

As I have seen in multiple forum entries, multithreading is supposedly 'less' efficient than using a single thread. I could understand how it would be harder to develop when you're having to use mutexes plus debug. I don't know to much about multithreading but wouldn't this also depend on the operating system the game is being executed upon? Could you explain why it is less efficient if that is in fact the case. ( I realize this is a different topic )

I won't be able to respond for a few hours; I'm going out. (The response time to a question on this forum is very fast!! :) )


Thanks for your help,

GCS


What i meant was that for commercial games, you will get better performance out of running a listen server rather than dedicated + client on the same machine.

Having said that, I also think that its better to run the game in a single thread. The first game i wrote using multi-threading TCP, it was fairly crap :). Then second game i decided to go for using a single thread in UDP, which ran much better. It was probably due to switching from TCP to UDP though, but it was much easier to impliment the single-threaded version. So I don't really see the need for multi-threading, you are just complicating things and making it harder to debug.

You do want to be sending data constantly, but this can easily be done at the start or end of each frame. Normally your frame rate will be higher than your networking update rate. If that is not the case then you need to think about improving your frame rate.

http://enet.cubik.org/ can be used as a single threaded UDP networking wrapper. Its great.

Share this post


Link to post
Share on other sites

Hello again,


A friend of mine showed me Raknet...http://www.rakkarsoft.com/

It appears as if this game network library is using multithreading. Is this the case?

Later,


GCS

Share this post


Link to post
Share on other sites
gcs584:

Sorry, I didn't mean to be confusing. What I meant was that you have to think about how your OS implements multi-threading. That is, they don't exactly run *at the same time* (assuming uni-processor). What it does is (very generally) switch back and forth really fast. Each time it switches however, it has to load the relevant details of each thread into the CPU. This may be registers and what not.

However! I took a quick look at the link you provided. Multi-threading may be ok for things that aren't time-critical (I mean, things that have to constantly update). For instance, code that retrieves data from the network layer, server-browser code, etc. This is (I think) because you can just simply let these threads block and let the real-time threads (eg. the game thread) take over.

Thing is, you don't really want the server code to run in a thread. By "server code" I mean any server-related code that runs in a tight loop. This thread will compete with your "client thread" (which also runs in a tight loop) for the CPU. This will most likely cause the OS to quickly switch back 'n' forth between the threads thereby causing a lot of overhead. Worse yet, the OS may decide to give a chunk of time to each thread causing the other thread to stall.

Anyway, I hope that makes more sense. Looks like you got your answer from the anonymous poster though.

-j

Share this post


Link to post
Share on other sites

This topic is 4836 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this