Mailing List Archive

setsockopt & keepalives
SGI had suggested we insert this into httpd.c next to the other setsockopt
calls, carte blanche - any comments? Is this a pretty non-portable patch?

int keepalive_value = 1;
if((setsockopt(sd,SOL_SOCKET,SO_KEEPALIVE,(const void *)&keepalive_value,
sizeof(keepalive_value))) == -1) {
fprintf(stderr,"httpd: could not set socket option\n");
perror("setsockopt");
exit(1);
}


Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
Re: setsockopt & keepalives [ In reply to ]
This patch is quite portable, but I wonder what problem they are
trying to solve. It hink the problem of a hanging TCP connection
would be bettered solved by a general timeout. A general timeout
would also solve the problem of connections that has SO_LINGER
set from living until the machine is reboot on some systems.

Cliff
Re: setsockopt & keepalives [ In reply to ]
>Date: Sat, 11 Mar 1995 18:18:55 -0800 (PST)
>From: Brian Behlendorf <brian@wired.com>
>SGI had suggested we insert this into httpd.c next to the other setsockopt
>calls, carte blanche - any comments? Is this a pretty non-portable patch?
>
>int keepalive_value = 1;
>if((setsockopt(sd,SOL_SOCKET,SO_KEEPALIVE,(const void *)&keepalive_value,
> sizeof(keepalive_value))) == -1) {
> fprintf(stderr,"httpd: could not set socket option\n");
> perror("setsockopt");
> exit(1);
>}

I think this patch is to fix a significant problem which some sites had
with httpd on (I think) SGI's and also Solaris, with some PC clients.
The client would exit without closing the connection, and so the server
would send periodic TCP data to the client for ever (something like 1 packet
every tens of seconds). When the number of such connections grew, sites saw
a significant fraction of their internet bandwidth going on these TCP
packets.

According to the Solaris 2.4 man page:
`SO_KEEPALIVE enables the periodic transmission of messages on a connected
socket. If the connected party fails to respond to these messages, the
connection is considered broken and processes using the socket are notified
using a SIGPIPE signal.'

Thus it seems to me that the cons will be increased network traffic, and
poorer tolerance to high latency networks.

David.