Date: Thu, 16 Sep 1999 23:20:02 +0200 (MET DST)
From: Gisle Vanem <giva AT bryggen DOT bgnett DOT no>
To: djgpp AT delorie DOT com
Subject: Re: DJGPP, WATT32: __FSEXT_alloc_fd() failed
In-Reply-To: <7rr51n$huh$1@nnrp1.deja.com>
Message-ID: <Pine.UW2.3.95.990916231104.28103B-100000@bryggen.bgnett.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, 16 Sep 1999, Richard Krehbiel wrote:

> I'm writing a DOS-based socket server, using DJGPP and WATT32.  This
> particular program needs to provide services to multiple TCP/IP
> clients.  In fact, *many* multiple clients - as many as 200.
> 
> I'm using WATT32's BSD socket API because (a) I'm familiar with it, and
> (b) I may one day (maybe sooner than I thought) end up porting this
> thing.
> 
> I found that the trick to providing services to multiple clients in
> WATT32 is like this:
> 
> for(;;)
> {
>   listen_sd = socket(...);
>   bind(listen_sd...);
>   listen(listen_sd...);
>   client_sd = accept(listen_sd...);
>   /* The client now owns *both* sockets!*/
>   start_client(listen_sd, client_sd);
>   /* iterate, creating a new listening socket */
> }
> 
> When the client socket client_sd is closed, the listening socket
> listen_sd is also closed.  This is because both are really references
> to the same underlying struct tcp_Socket in the WATTCP API.
> 
> Okay so far...

This is going to change in next version (2.1) to a BSD-compliant behaviour.
Pending SYN's (backlogged connections from listen) are not handled either.
If you have an idea on how to fix this, please contribute a fix.

> The problem I'm hitting now is that I'm getting the error message noted
> in the subject line at the point where watt32's socket.c would be
> allocating file descriptor 20.  Huh?  I've been unable to find the
> source of this limitation.  socket.c calls __FSEXT_alloc_fd, which
> itself just dups an open handle to the DOS NULL device, and otherwise
> appears not to impose any 20-handle limit (and a comment in
> __FSEXT_alloc_fd indicates that the decision to DUP and not open a new
> NUL device handle is to avoid the FILES= limit).

Do you use an old djgpp? OTOH, this dup-trick was introduced in v2.01.
Maybe DOS keeps these dup-reference in a table (System File Table?) and 
when this table becomes full not even NULL can be dup'ed.
 
Gisle V.