Jump to content

  • Log In with Google      Sign In   
  • Create Account


select() in server


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
13 replies to this topic

#1 Demx   Members   -  Reputation: 298

Like
0Likes
Like

Posted 18 October 2012 - 07:54 AM

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

Sponsor:

#2 swiftcoder   Senior Moderators   -  Reputation: 9584

Like
1Likes
Like

Posted 18 October 2012 - 08:05 AM

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

Generally, yes. Better yet would be one of io-completion-ports/epoll/kqueue, or a wrapper thereon.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#3 Demx   Members   -  Reputation: 298

Like
0Likes
Like

Posted 18 October 2012 - 08:22 AM

is http://www.codeproject.com/Articles/20066/A-scalable-client-server-using-select-socket-funct#_comments a good base on which to start ?

#4 KnolanCross   Members   -  Reputation: 1159

Like
0Likes
Like

Posted 18 October 2012 - 06:41 PM

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.
My blog on programming and games.
http://16bitsflag.blogspot.com.br/

#5 swiftcoder   Senior Moderators   -  Reputation: 9584

Like
2Likes
Like

Posted 18 October 2012 - 06:47 PM

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.

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).

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#6 KnolanCross   Members   -  Reputation: 1159

Like
0Likes
Like

Posted 18 October 2012 - 07:31 PM


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.

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).


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.
My blog on programming and games.
http://16bitsflag.blogspot.com.br/

#7 hplus0603   Moderators   -  Reputation: 4960

Like
0Likes
Like

Posted 18 October 2012 - 10:46 PM

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?
enum Bool { True, False, FileNotFound };

#8 KnolanCross   Members   -  Reputation: 1159

Like
0Likes
Like

Posted 19 October 2012 - 08:35 AM

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?


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 Posted Image

Edited by KnolanCross, 19 October 2012 - 08:37 AM.

My blog on programming and games.
http://16bitsflag.blogspot.com.br/

#9 hplus0603   Moderators   -  Reputation: 4960

Like
1Likes
Like

Posted 19 October 2012 - 10:30 AM

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


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.
enum Bool { True, False, FileNotFound };

#10 KnolanCross   Members   -  Reputation: 1159

Like
0Likes
Like

Posted 19 October 2012 - 12:02 PM

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


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.


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, 19 October 2012 - 12:11 PM.

My blog on programming and games.
http://16bitsflag.blogspot.com.br/

#11 BeerNutts   Crossbones+   -  Reputation: 2555

Like
1Likes
Like

Posted 19 October 2012 - 01:22 PM

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:

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
  }
}

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

#12 Katie   Members   -  Reputation: 1281

Like
0Likes
Like

Posted 19 October 2012 - 01:24 PM

"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).

#13 KnolanCross   Members   -  Reputation: 1159

Like
0Likes
Like

Posted 19 October 2012 - 02:02 PM

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, 19 October 2012 - 02:03 PM.

My blog on programming and games.
http://16bitsflag.blogspot.com.br/

#14 FlyingDutchman   Members   -  Reputation: 207

Like
0Likes
Like

Posted 22 October 2012 - 01:04 PM

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:


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


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.

http://linux.die.net/man/2/select
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, 22 October 2012 - 01:08 PM.

I open sourced my C++/iOS OpenGL 2D RPG engine :-)


See my blog: (Tutorials and GameDev)

http://howtomakeitin....wordpress.com/





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS