CallSignalHandlerNumber should be to some empirical value that maximizes throughput of signaling messages. If you use sophisticated authentication and accounting, you may want to have many call signal handlers to achieve high calls per sec. rate. and minimize parameters like PDD. Maximum number of concurrent calls is (theoretically) not dependent on CallSignalHandlerNumber. If you can process signaling messages very, very fast, you can have only one call signal handler. In Windows, you have compile-time constant, FD_SETSIZE, which defines maximum handle limit per FD set. This, in turn, results in a maximum limit for a single thread. The default is 64, as you noted. I don't know what is Windows per process default, but on systems without an explicit resource control it can be as large as a number of available sockets in the system. ----- Original Message ----- From: "Freddy Parra" <fparra@xxxxxxxxxx> Sent: Tuesday, August 31, 2004 4:44 PM This brings up an interesting question as to how Linux and Windows define file descriptors. I was under the impression that if the OS has FDSET defined as 1024 per process then each thread had the capability to open 1024 file descriptors. Which is why we would want to increased call signaling handlers in gnugk. It seems that for Linux this is not the case and all threads share the max limit defined for a process by the OS. Then what would be the default value for a thread in linux? In windows this seems to be different, the default is 64 per thread or is there a default max per process regardless of how many threads the process is using for Windows? Freddy ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
