Hi Nick, On Mon, Feb 15, 2010 at 10:05:57AM +0000, Nick Chalk wrote: > Hello Willy, Krzysztof. > > On 13 February 2010 10:40, Willy Tarreau <w...@1wt.eu> wrote: > > On Fri, Feb 12, 2010 at 05:47:41PM +0100, Krzysztof Ol??dzki wrote: > >> There are several issues with the fix: > >> > >> - we need to check if connection is not closed, as it is pointless to > >> use MSG_PEEK and restarting such check if there is no more data we are > >> able to read > > > > Indeed, with MSG_PEEK we have no way to tell the connection was closed. > > For the time being, I've hacked together a patch to get our customer > up and running. > > I've allocated a new static character buffer, to store the > intermediate results from the real server. I'm relying on recv() > returning a length of 0 to indicate the server has closed the > connection - not sure if that's a reliable method, but it seems to be > repeatable.
It will not always work with MSG_PEEK. It will only return that if the server closes without sending any data. However if it sends some data first, every subsequent recv(MSG_PEEK) will return those data, so you'll never detect the close. That's what Krzysztof explained when he said that we'd rely on timeouts even when servers return short responses. Maybe we could try to use some non-portable methods to try to detect a close (eg: getsockopt(fd, SOL_SOCKET, SO_RCVBUF) to see if the input buffer is closed, etc...). But I don't even think it would work, and even if it did it would be terribly tricky. The other temporary solution will be to allocate a receive buffer to every server to store health check responses. This might not be that hard in fact, and maybe we can even do that during 1.4 maintenance as it would be a nice improvement with very little risk of regression. Regards, Willy
