Jump to content
  • Advertisement
Sign in to follow this  
MickeyMouse

Server and Client - in the same thread?

This topic is 5048 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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!