Re: Issues related with server architechture

From: Barry Margolin (barmar_at_alum.mit.edu)
Date: 02/02/05

  • Next message: Thomas Dickey: "Re: ncurses line clipping" 
    Date: Wed, 02 Feb 2005 06:02:00 -0500

    In article <b49ef75a.0502020227.1e6d8098@posting.google.com>,
     myself_rajat@yahoo.com (Rajat) wrote:

    > Hi all,
    >
    > I am working for an server application, using TCP at transport layer.
    > It will be a kind of routing information management through server for
    > all the connected client. Means every client will interchange some
    > information with server time by time, and based on that information
    > server build a table for routing information, and further send the
    > require information to the clients back.
    >
    > Now I have some issues related with server's architecture. Shall I go
    > for mutithreaded architectue, like one thread will be for main socket
    > for ACCEPTING the new connections, and for each new connection again
    > create new thread. OR there will be one thread for ACCEPTING the new
    > connections, and one other thread will handle all the clients
    > connections, using select and all.
    > Other than that if you have any other better idea then plz let me
    > know.

    It depends on how many concurrent clients you need to support. You
    don't want to have lots of threads, because the scheduling overhead may
    bog you down. You might want to use a cross between the two techniques,
    using a pool of worker threads.

    >
    > One more thing suppose we are SELECTING a set of sockets for
    > readability using select, if any one socket is ready for reading, to
    > find which socket is readable using a loop from MIN socket descriptor
    > to MAX socket descriptor is really very costly if we have a large
    > number of sockets to select. As well as at a perticular point of time
    > there may be more than one sockets will be readable, So a readable
    > socket having greater socket descriptor may suffer from STARVATION. Is
    > there any way So that we can get exactly that socket descriptor which
    > is ready to read.

    You could search from prev_descriptor+1 -> MAX, MIN -> prev_descriptor.
    This will prevent the low-numbered descriptors from getting priority. 

    -- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
  • Next message: Thomas Dickey: "Re: ncurses line clipping"
    Loading