- From: Wayne W. Ziebarth <ziebarthw@mailmyemail.com>
- Date: Mon, 30 Apr 2001 05:45:25 -0700
- 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. Thanks, Wayne Ziebarth
Received on Monday, 30 April 2001 06:46:14 UTC