Mail Archives: djgpp/1999/09/16/20:20:49
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.
- Raw text -