W3C home > Mailing lists > Public > www-lib@w3.org > April to June 2001

HTDoAccept() and closing the listening socket.

From: Wayne W. Ziebarth <ziebarthw@mailmyemail.com>
Date: Mon, 30 Apr 2001 05:45:25 -0700
Message-ID: <013c01c0d173$6e4da380$bdb6c8d0@ctcdist.com>
To: <www-lib@w3.org>
I get the feeling from searching the message list archive that using libwww
as a server is not a popular subject (probably since the library was
designed for
client use), but I got up the courage to ask anyway.

For the last 2 weeks I have been using HTTPServ.c and the listen.c example
application as models for a simple server application. I noticed in
HTTPServ.c there weren't calls to listen on a socket or read from a socket,
so I took some of the techniques from HTSocket.c (which is used by listen.c)
and added it to my version of HTTPServ.c.

Things worked pretty good to service a single request. It listens on the
specified port, does an accept when an external client does a connect on the
port, and executes the code to service the request. However, when the
HTDoAccept (called from HTHost_accept()) returns HT_OK rather than
HT_WOULD_BLOCK, it closes the listening socket (the SOCKET that was set in
HTDoListen() - 68 in my case), and sets the new socket (in my case 72) to
both the listening and accepting HTNet's, because there is only one SOCKET
variable maintained at the HTHost or HTChannel level.

The next time an HTDoAccept() is called, instead of using the original
listening socket, it is passed the socket (72) returned by the successful
accept() and the OS returns an error that the socket is not open for
listening - which is true. To make it work the way I thought it should, I
created a static local SOCKET variable in HTDoAccept() that would maintain
and use the listening SOCKET, rather than that obtained via the call to
HTNet_socket( listening ). That way, it is passed 68 as the socket the
second time and not 72. This does seem to work.

Is there something I am doing wrong or should be doing differently at a
higher level in the application to avoid this problem? Any feedback or
direction would be greatly appreciated.


Wayne Ziebarth
Received on Monday, 30 April 2001 06:46:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:54 UTC