[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

8496.0. "URGENT: ***KEEPALIVE***" by ATYISA::ABULIUS () Fri Jan 17 1997 11:13

T.RTitleUserPersonal
Name
DateLines
8496.1SMURF::MCCANNMon Jan 20 1997 09:0018
8496.2TPOVC::SIMONLEEFri Mar 21 1997 11:4811
    
    I got the same problem and checked the reference page of setsockopt but
    did not see TCP_KEEPIDLE option. Is it in old version or does it belong
    to different protocol level? I also checked the tcp_keepalive value of
    kernal and it was 1440. If its unit is second, then it is 24 minutes
    instead of 2 hours. How come? If I don't set SO_KEEPALIVE, will the
    socket never disconnect?   Please advise. Thanks in advance.
    
    /Simon
    
    
8496.3TPOVC::SIMONLEESun Mar 23 1997 20:323
    
    Sorry, I made a mistake, the keepalive value in kernel is 14400, that
    is 4 hours.
8496.42 hours is rightSMURF::DUSTINMon Mar 24 1997 10:245
    The keepalive value is specified in units of 1/2 seconds, so it's
    actually 2 hours, not 4 hours.
    
    John
    
8496.5SIGPIPE not sent for TCP_KEEPALIVETPOVC::SIMONLEEMon Mar 24 1997 20:4024
    
    Thanks!
    
    About the setsockopt(), just the other days, I wrote a program to test
    the SO_KEEPALIVE option. I set the tcp_keepidle to 60 and tcp_keepintvl
    to 5, so I didn't need to wait for two hours for the tCP to probe the
    other party. I connected to my program (server) from a client and used
    tcpdump to examine the traffic. I unplugged the network cable from the
    client and after a moment (I believe is the time I set for
    tcp_keepidle), the server started to probe the client. Everything
    seemed good, after 10 probes, the connection is broken and the server
    exited. This is what I didn't expect because I had captured the PIPE
    signal and in the signal handler, I did something, but those things had
    not been done. That meant the PIPE signal had not been sent. If I sent
    PIPE signal explicitly with "kill -pipe", the handler did be called.
    According to 0. and reference manual, system should send a pipe signal
    to the process using the socket, but it didn't. What could be the
    possible cause of it? Does anybody have the same experience?
    
    I am using UNIX V3.2C. Please advise. Thanks.
    
    /Simon
    
    
8496.6VAXCPU::michaudJeff Michaud - ObjectBrokerMon Mar 24 1997 21:1010
Re: .5

	I'm not sure I understand what you are saying, but do note that
	a SIGPIPE signal is only sent syncronously when you write(2) or
	send(2) on a pipe (or socket, etc) that is not connected.

	Ie. you will not get a SIGPIPE signal at the time the transport
	has marked the socket as disconnected.  You should however get
	a SIGIO, if you've marked the socket for async io, and setup
	a signal handler.
8496.7TPOVC::SIMONLEEThu Mar 27 1997 21:2828
    
    Re: .6
    
    This is what the setsockopt() MAN page says about SO_KEEPALIVE option:
    
          SO_KEEPALIVE
                Keeps connections active.  Enables the periodic transmission
                of messages on a connected socket.  If the connected socket
                fails to respond to these messages, the connection is broken
                and processes using that socket are notified with a SIGPIPE
                signal.
    
    It does not say wheather the processes using the socket is doing
    read/receive or write/send will be notified with SIGPIPE. If, according
    to you, the SIGPIPE is only sent to the processes that are doing
    write/send on a connected socket, then the phenomenon is right because
    my program is doing receive operation. If the socket will be
    disconnected automatically after failed keepalive probes, that's fine
    and it means I don't need to capture the SIGPIPE signal and close the
    socket explicitly. Any comments?
    
    /Simon