Re: Turn off a PC:Problems on C/S

Mark Bradshaw (not@hoople.demon.co.uk) wrote: : The recent discussion has gone something like: : > cwakins@leia.alloys.rmc.com "Clem Akins" writes: : ><snip> : >> Buenos dias! : >> : >> The answer below appeared a while ago, maybe it will help. : >> : >> _ This problem is caused by not using the SO_KEEPALIVE option on the socket. : >> _ If the option is omitted there is no way to tell that the end point : >> _ (i.e. PC) is dead. Check out the options for the Q+E driver on how to : >> _ set this from the PC side and your problem will disappear. : and from sally@excelsis.demon.co.uk: : >Can this also apply to any type of networked connection? Can is also : >sometimes lead to the 'left-behind' process eventually producing a core : >dump & exiting? : SO_KEEPALIVE is, as far as I know, a TCP/IP-only option. It is present : because on wide area networks it is difficult to tell if the remote site : has disappeared or is just taking a while to respond. : If SO_KEEPALIVE is enabled at BOTH ends of the connection then what : happens is when the server has not heard from the client for a specified : period of time if sends a "Are you there?" packet to the client to see : if the client is still there. If no reply, it tries again a few times : and, presuming no response, closes the processes which were using the : socket. : On the UNIX systems I have looked at this the server waits for 2 hours : before checking on the client. It then sends 5 or 6 "hello" packets : spaced at about 5 minute intervals before shutting down the socket. So : your "left-behind process" on the server Sally will remain for 2 and a : half hours before being closed down (and possibly coredumping - depends : on what it was doing when the connection was lost). : So, having turned on the option on your Q+E driver (or application on : PC) you might also want to tune the KEEPALIVE timeout value on the UNIX : server as 2 hours is a bit much if WANs are not involved. I've tuned : this parameter down to saying "hello?" after 10 minutes with no : noticable affect on network traffic. : Hope this helps. E-mail for more info! : -- : Mark Bradshaw (not) not@hoople.demon.co.uk With AT&T system 5 unix and win-tcp there are timers just like the ones noted. TCP_KEEPCNT for the number of probes and TCP_KEEPINT for the time between probes. There is another setting that needs to be set in the /etc/conf/pack.d/tcp/space.c file for tcp_linger which should be set to like 6. The other parameters should be played with in order to get the best working condition. This should take care of those pesky socket connections that just tie up the istar daemon. Rb.