delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/09/16/14:59:59

From: rich AT kastle DOT com (Richard Krehbiel)
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.os.msdos.djgpp
Subject: DJGPP, WATT32: __FSEXT_alloc_fd() failed
Date: Thu, 16 Sep 1999 16:14:59 GMT
Organization: Deja.com - Share what you know. Learn what you don't.
Lines: 45
Message-ID: <7rr51n$huh$1@nnrp1.deja.com>
NNTP-Posting-Host: 206.27.76.2
X-Article-Creation-Date: Thu Sep 16 16:14:59 1999 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)
X-Http-Proxy: 1.1 x27.deja.com:80 (Squid/1.1.22) for client 206.27.76.2
X-MyDeja-Info: XMYDJUIDrichkxxx
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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...

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).

Well, I already had FILES=30, so I suspected this was not the problem,
but just in case, I increased it to FILES=200.  There was no change.

Thanks in advance for any help.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019