Sockets: Too many open files on a sequent under dynix

Clay Luther cluther at supernet.dallas.haus.com
Tue Apr 23 01:40:31 AEST 1991


Hello:

I do not usually read this group, so please email replies to me at
cluther at supernet.haus.com *or* cluther at ponder.csci.unt.edu.  Thanks.

I am working with a program that allows creates an telnet port which users can
connect to and access a database interactively.  Standard Berkeley socket
stuff.  This is on a sequent.

However, when several users (around 8) begin to access the database, the
program can no longer open the database files.  The error returned is "too many
files open".

Checking NFILES in stdio.h reveals 20.

There are only 5 files attached to the database that users would access, and
the code only allows at most 2 files to be open by one user at any time.  The
transaction path follows:

  User 1 request -> files open -> process -> files closed -> User 2 request ->
  files open -> process -> files closed -> ... User n request -> ... ->
  User 1 request -> ...

That is, each user is served in round-robin fashion, each accessing the
database for a very short amount of time.  Therefore, at most two files are
open *at any time*.

I have checked the code thoroughly for dangling open files...none exist (well,
as far as I can tell).

However, when about 8 users log onto the database, a 9th user will cause a "too
many files open" error.  The code will run indefinitely with up to 8 users
logged on.

I have begun to think that the sequent is charging 2 files, one for input and
one for output, for each telnet connection to the program.  Is this true?
And if so, are there any work arounds, or will I have to restrict the maximum
number of users my program can handle at one time due to a kernel limitation?

Thanks!
-- 
Clay Luther, Postmaster          cluther at supernet.dallas.haus.com 
  Harris Adacom Corporation      cluther at enigma.dallas.haus.com
  Voice:  214/386-2356           MS 23, PO Box 809022, Dallas, Tx 75380-9022
  Fax:    214/386-2159           Your mileage may vary.  Void where prohibited.



More information about the Comp.unix.programmer mailing list