• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Demx

select() in server

13 posts in this topic

IS it better to use select() and synchronous sockets to make a 2D online game server, rather than many threads per client ?
0

Share this post


Link to post
Share on other sites
[quote name='Demx' timestamp='1350568496' post='4991428']
IS it better to use select() and synchronous sockets to make a 2D online game server, rather than many threads per client ?[/quote]
Generally, yes. Better yet would be one of io-completion-ports/epoll/kqueue, or a [url="http://libevent.org"]wrapper thereon[/url].
1

Share this post


Link to post
Share on other sites
is [url="http://www.codeproject.com/Articles/20066/A-scalable-client-server-using-select-socket-funct#_comments"]http://www.codeproject.com/Articles/20066/A-scalable-client-server-using-select-socket-funct#_comments[/url] a good base on which to start ?
0

Share this post


Link to post
Share on other sites
When I had to choose I went for multiple threads model because most cpus nowadays are multi-core, so a multi-threaded application is more likely to scale better.
0

Share this post


Link to post
Share on other sites
[quote name='KnolanCross' timestamp='1350607314' post='4991608']
When I had to choose I went for multiple threads model because most cpus nowadays are multi-core, so a multi-threaded application is more likely to scale better.[/quote]
There is no scaling if all you are doing is using threads to implement non-blocking I/O. Now, if you are also processing data in each those threads, well, that's a different story (with its own pros and cons).
2

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1350607655' post='4991609']
[quote name='KnolanCross' timestamp='1350607314' post='4991608']
When I had to choose I went for multiple threads model because most cpus nowadays are multi-core, so a multi-threaded application is more likely to scale better.[/quote]
There is no scaling if all you are doing is using threads to implement non-blocking I/O. Now, if you are also processing data in each those threads, well, that's a different story (with its own pros and cons).
[/quote]

Well observed.
You should be using a blocking interface along with a timeout (such as set_sock_opt) or a single file descriptor select (in my case) so you can update each thread and also have them in the sleep process most of the time.
0

Share this post


Link to post
Share on other sites
If you ever find yourself needing to sleep a thread, you're doing something wrong. You should be using blocking I/O (and other primitives, like condition variables, events, etc,) and be driven by that. If your OS has no native unblocking timers, and you need to step at a fixed rate, it's OK for one thread to use a timeout-wait for blocking primitives to implement that.

If you use thread-per-client for "scaling," exactly what is each of those threads doing? How are you avoiding those threads stepping on each others toes while mutating your world?
0

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1350621967' post='4991674']
If you ever find yourself needing to sleep a thread, you're doing something wrong. You should be using blocking I/O (and other primitives, like condition variables, events, etc,) and be driven by that. If your OS has no native unblocking timers, and you need to step at a fixed rate, it's OK for one thread to use a timeout-wait for blocking primitives to implement that.

If you use thread-per-client for "scaling," exactly what is each of those threads doing? How are you avoiding those threads stepping on each others toes while mutating your world?
[/quote]

By sleep i didn't mean the sleep function, I meant the OS' sleep state.

In my case I had threads to receive info/send updates to clients and threads to update the world state. To avoid running conditions I used a lot of mutexes and a zone approach to filter data (data in a zone could be changed without affecting others). It was indeed pretty annoying to implement it, but I learned a lot. How he will model his world is up to him [img]http://public.gamedev.net//public/style_emoticons/default/happy.png[/img] Edited by KnolanCross
0

Share this post


Link to post
Share on other sites
[quote]By sleep i didn't mean the sleep function, I meant the OS' sleep state.[/quote]

It may be a terminology thing. The way I understand it, a thread enters "sleep" state by calling sleep() or similar functions. This is different from the "blocked" or "wait" state which is when a thread is actually waiting on something else to happen.

Also, if you use mutexes in your threads, you won't actually scale across cores, because your threads will end up serializing on whatever the common data structure is. Thus, you can save memory, CPU overhead, and programming complexity by using select() or non-blocking sockets instead of multiple threads for your networking.
1

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1350664255' post='4991815']
[quote]By sleep i didn't mean the sleep function, I meant the OS' sleep state.[/quote]

It may be a terminology thing. The way I understand it, a thread enters "sleep" state by calling sleep() or similar functions. This is different from the "blocked" or "wait" state which is when a thread is actually waiting on something else to happen.

Also, if you use mutexes in your threads, you won't actually scale across cores, because your threads will end up serializing on whatever the common data structure is. Thus, you can save memory, CPU overhead, and programming complexity by using select() or non-blocking sockets instead of multiple threads for your networking.
[/quote]

Yeah, it is terminology, afaik even the sleep call is an io block state, waiting for the os to "wake" the process, for instance sleep (10) will make your program stay in the wait state for 10 seconds, while a blocking receive will be in wait state until new data arrives. Anyways, I meant that the process would be in a blocking state and would not consume CPU.

About the mutexes I can see your point but I respectfully disagree.
Mutexes are not active wait, in other words when you reach a locked mutex, your thread enter a wait state, thus it won't consume cpu. In my case, although I had some threads locked in the same mutexes, there were others that were not. So I was using the multiple CPU cores at the same time, this is a huge gain in performance.
There is, of course, an increase use of memory and there is an overhead for the scheduler (since there were multiple threads). Edited by KnolanCross
0

Share this post


Link to post
Share on other sites
IMO, you're going to cause more pain than needed for using multiple threads for each client's connection, and for little (if any) benefit.

You could create 1 thread to handle all client connections, and just check all the clients sockets with select, or, you could treat the client connections portion as you would any other part of a typical game loop update:

[code]
while(IsRunning) {
UpdateClients();
UpdateWorld();
// etc...
}

void UpdateClients() {
struct timeval timeout;
timeout.tv_sec = 0;
timeout.tv_usec = 0;
// assuming you modify the file descriptor on client connect and disconnect...
int clientsReady = select(NumClients, &ClientFDs, NULL, NULL, &timeout);
if (clientsReady > 0) {
// process the clients
}
else if (clientsRead == -1) {
// handle error
}
}
[/code]
1

Share this post


Link to post
Share on other sites
"When I had to choose I went for multiple threads model because most cpus nowadays are multi-core, so a multi-threaded application is more likely to scale better."

You'll still need to use a multiplexing. Why? Because you don;t want the threads (and hence their attendant data structures) being scheduled all over the place. If you have more threads than cores, you run the risks of either threads being runnable but not running (because they're current assigned to cores which are already running something else), or being moved to another core requiring a lot of memory controller bandwidth (which slows down your thread working).

Ideally, you should be looking to have just less threads runnable at the same time than cores; leave a couple of cores for the OS and generally it'll happily settle into the gap and not thrash with you. This means your threads exhibit effective soft core affinity but without all the aggravation that real affinity brings (presuming your OS will even let you do it).
0

Share this post


Link to post
Share on other sites
I believe this may be going away off-topic... again, I will respectuffly disagree (and by that I mean: I can see your point, they are correct, but I put different weights on the advantages/disavantages than you).

1) Schuduling multiple threads is a only problem when they are all working non-stop. It is not the case here, since each thread will work for a very short period of time and get back to the wait state.

2) Didn't really got the problem of falling on different core. The only problem I can see is a cache miss, but if you are working with a single core and a lot of data, you are very likely to face this problem anyway.

3) Still on the different core issue. A single process approach will enter on IO wait in the select and may also be processed by a different core each time.

I would like to point again that I am not saying that this is the mathematically proven best approach or that it won't run into problems. The way I see it, the way OS' handle multi threading will improove a lot in the next years and CPUs will have more and more cores, so this would be the way to go (not only for having a better application, but also to gain the knowledge about it). Edited by KnolanCross
0

Share this post


Link to post
Share on other sites
[quote name='BeerNutts' timestamp='1350674556' post='4991876']
IMO, you're going to cause more pain than needed for using multiple threads for each client's connection, and for little (if any) benefit.

You could create 1 thread to handle all client connections, and just check all the clients sockets with select, or, you could treat the client connections portion as you would any other part of a typical game loop update:

[code]

int clientsReady = select([b]NumClients[/b], &ClientFDs, NULL, NULL, &timeout);
if (clientsReady > 0) {
// process the clients
}
else if (clientsRead == -1) {
// handle error
}

[/code]
[/quote]

numClients is a bit wrong here. The first argument shall not be the number of fds in your fdset but the number of the highest fd to check + 1.

[url="http://linux.die.net/man/2/select"]http://linux.die.net/man/2/select[/url]
nfds is the highest-numbered file descriptor in any of the three sets, plus 1.

Its also worth mentioning that ClientFDs and timeout should be reinitialized after select.

To answer the question:

Go for async IO and use select/kqueue/poll or whatever else you like. select is pretty easy to use , even tho a bit confusing at first. especially if you want to to asyncronous write operations as well or add fds from files to your select queue to do asynchronous file access to the OS. But i know from back in the days that UOX2 (a very famous Ultima Online freeshard) was coded with select and ran great. Later one they added threads etc to leverage level loading and other stuff but in the beginning everything was one thread and async IO. I think thats anyway the way to go for online rpgs. You should just take care not to do put too much stuff in each cycle of the main loop. But thats where sharding comes into the picture. For example, Ultima Online (the real one), had multiple servers per world. Edited by FlyingDutchman
0

Share this post


Link to post
Share on other sites

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  
Followers 0