Thread: Pros and Cons of blocking versus non-blocking sockets?

  1. #1
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195

    Pros and Cons of blocking versus non-blocking sockets?

    OK, normally I use blocking sockets because they reduce processor overhead when dealing with only a small number of connections (1-5), but now I am going to be working with an application that will have potentially hundreds or thousands of simultaneous connections. The method I use right now is to have one thread listen() and accept() connections and then spawn a new thread for each client. This works great in my at most 5 clients applications, but I am wondering how well it will do with hundreds. I only expect each connection to be transferring about 4KB per second, at most 10 times per second. I was thinking of using select to check for data and Sleep(0) to pass control if there is none.

    I would prefer to stick with a multithreaded model if possible, since it scales better, but I'm open to suggestion.

  2. #2
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    I'm a fan of using multiple non-blocking sockets and some cousin of poll() or select(), such as epoll() - find programming for it easy enough. epoll() can also keep the multithreaded issues smaller or non-existant. I thought you were a die-hard thread person?

    Granted, I've never actually taken either of epoll() or threads to extreme levels. What I've read say epoll() should scale well, but I really ought to take a couple methods for a test someday.
    C10K is always a good read, though, and their point on threads is that you just have to watch stack sizes so as to not run out of memory.

    transferring about 4KB per second, at most 10 times per second
    4KB/sec. Ten times / sec. 40KB / sec ? *loses braincells*
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  3. #3
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    I am a die-hard threader, i just dont want to get 6 months into the project before I find out I have to rewrite the network code to be non-blocking. Yeah launching several thousand threads isnt an issue as long as you specify a smaller default stack size. Default size is 1MB, which is overkill for just about everything. A more reasonable size would be 64k. The stack can of course grow, but it has to be big enough to handle the initialization code (setting up local variables, etc). The real issue is keeping them from all trying to execute at once.

    Its 4KB per second total, 10 sends of about 400 bytes per second. At least that is my ballpark figure. Hopefully it will be less, since it will be on a metered server.

  4. #4

  5. #5
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Codeplug is da MAN! Good article, I forgot about the 64KB granularity limit, Ill probably have to go with nonblocking code and an object based connection scheme. Thanks for saving me one helluva headache down the road

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 8
    Last Post: 08-18-2008, 05:31 PM
  2. Computers. Pros. Cons.
    By Sentaku senshi in forum Tech Board
    Replies: 13
    Last Post: 08-21-2002, 09:43 AM