Sign in to follow this  

(theoretical) Nonblocking vs thread-per-connection in a textbased online rpg

This topic is 4865 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

I have been tossing this idea around in my head for a while, and I'm just not sure how I would want to do this if I got around to it. Lets say I have a game, and the server is going to be limited to 75 connections at any given time. Is 75 threads too much for a machine to handle? And to state again, it is text based, so there won't be alot of data moving back and forth, as almost all of the data is going to be processed on the server. On the other hand, if I use select non-blocking sockets for the server, its going to be hard to process all of the data like i want to. Well, it won't be alot of calculations per command, but they will still all be fighting for time. A little more about my design, you can do whatever you want in a room. But your movment is limmited to 1 room every 30 seconds. so you can't just go on a bombing run to kill somebody, and i'm limmiting the number of people in any given room to 5.

Share this post


Link to post
Share on other sites
I'm curious, why should the non-blocking way make it more difficult to process the data how you want?

The way I do it is create a single UDP socket for both sending and recieving, then every frame I call select() to see if the socket recieved anything, and recv/recvfrom if it did.
This way it's nonblocking, there is 1 thread, 1 socket, and as many connections as you want.(Although, I have not tested this with more than 16) and it's also crossplatform.

Share this post


Link to post
Share on other sites
nonblocking udp?
It could work...
but how would you handle connection interupts and lost packets?
with tcp/ip, you can check for a disconect.
I'm willing to try it though.

Share this post


Link to post
Share on other sites
If you've already made the decision to use TCP connections (as opposed to UDP connectionless packets), then the answer is no, 75 threads is not too much for a machine to handle. I've written a system that uses a few hundred threads for pushing reverse DNS lookups to a DNS server as fast as possible, and the firewall crashed before the CPU on my system broke a sweat. ;-) Even with a better firewall, the system handled the threads with no problems at all.

Of course, I could've used other approaches that would've been more efficient, like the UDP approach Melekor mentioned, but I was using a third-party DNS resolver and my project schedule didn't provide time to write my own DNS resolver.

If you'd prefer a clean and simple implementation, use the threaded TCP approach. If you need the utmost efficiency and scalability, look at UDP (perhaps with threads and perhaps without).

Share this post


Link to post
Share on other sites
Quote:
Original post by PnP Bios
nonblocking udp?
It could work...
but how would you handle connection interupts and lost packets?
with tcp/ip, you can check for a disconect.
I'm willing to try it though.


With UDP you have to implement your own timeouts, wakeup packets, retries, and so on. It can be a pain if you need it to be as reliable as TCP, especially around testing and debugging all of the possible exceptions to make sure they're handled correctly.

Share this post


Link to post
Share on other sites
Ok, if the thread method would work, than that's what I would go with.

It seems to me that UDP would best be suited for something like an FPS, where you are going to be slinging a packet on every frame, and it wouldn't matter if you lost a couple here or there.

Thanks for the advice everybody!

Share this post


Link to post
Share on other sites
It's funny to hear someone say that, with non-blocking sockets (and hopefully, select()), the clients will be "fighting for time," and then suggesting a system with 75 threads.

If there's only a single CPU in the system, then those 75 threads will be fighting for time, too. Except all those threads means that you have to use locking, which adds overhead to your program, compared to the single-threaded model where you know you're the only reader/writer and thus need no locking. Thus, single-threaded means less overhead AND fewer locking bugs.

A typical single-threaded application using TCP and select() will do something like:


forever {
put fds with buffered data into write set
put all fds into read set
select() on file descriptors with timeout of a single game tick
for each ready-to-write fd {
write stuff out of the buffer
}
for each ready-to-read fd {
read stuff into the input buffer
}
if enough time passed since last game update {
for each entity/player/whatever, parse commands and update state
}
}


Note that everyone sending data for a specific tick, will be served during that tick. There's no "fighting for time" going on. If everyone sends too much data such that you can't keep up, well, you can't keep up, and the world will "tick" slower. With a multi-threaded approach, making things happen in a predictable order at a predictable rate is much harder.

Of course, most people who put 75 threads in a program, then realize that synchronization is hard, and avoiding deadlock is even harder, so they add one big lock for "the world". Then, each of the threads will compete for that single lock, and who gets serviced when is significantly less fair than with the single-threaded solution.

So, won't multiple threads scale better on multiple CPUs, and pay for the synchronization overhead? Well, they might, if your program is well decoupled and processing-intensive, like a ray tracer. It probably won't, if everything interacts with everything else, and processing is memory-bound, like in a shared world...

Share this post


Link to post
Share on other sites
That's what I would recommend. In my previous post I talked about UDP sockets but the select scheme will work fine with TCP too, except you will need a socket for each connection. And then you won't have to worry about packet loss, etc. Basically what hplus0603 said. =)

Share this post


Link to post
Share on other sites

This topic is 4865 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