TUna

Members
  • Content count

    91
  • Joined

  • Last visited

Community Reputation

122 Neutral

About TUna

  • Rank
    Member
  1. Non-blocking connect()?

    Use "select" to determine if the socket is write ready or in an error state.
  2. Quote:Original post by hplus0603 Quote:TCP is actually the prefered solution for scalability. The worst part of lots of TCP sockets isn't the kernel-mode bloat, though, but instead the increase in I/O cost when the kernel has to sift through 5,000 sockets each time. There are ways to mitigate this, but it's not as simple and efficient as a UDP server, from this point of view. But if you use UDP all you do is move this sifting code from the kernel to your application. At some level you are going to have to map a packet to a client instance, whether this is done in the kernel or your app, is up to you. Many MMOGs use TCP exclusively, including World of Warcraft.
  3. If you're using TCP, recv will return 0 bytes indicating the connection has been closed/dropped. Direct from MSDN: If no error occurs, recv returns the number of bytes received. If the connection has been gracefully closed, the return value is zero. Otherwise, a value of SOCKET_ERROR is returned. So your code can do a simple check if bytes <= 0. Assume the connection has closed.
  4. Depends how many connections you're expecting... If its going to be 4 to 8 player, its probably not an issue, but probably still an overkill, you could probably get away with one thread and plain select/poll for 4 to 8 player. If you plan to have 100s of connections then this would definately be a problem as the overhead of all the threads starts to hinder performance. All your connections are not active all the time, so rather share your connections across a bunch of threads. You can then tweak the size of your worker pool for optimum performance.
  5. Most servers use a combination of both the methods you mention. I'd recommend have a N threads that service M connections, where M is usually greater than N. The way my engine works is to have one thread that continously uses select/poll to find sockets that have data waiting. It then reads the data and puts the messages into an inbound queue. I then have 5 to 10 worker threads that pull jobs from the inbound queue and process them. Make sure you put the required Mutex/Semaphores around your queues.