Return to BSD News archive
Xref: sserve comp.unix.programmer:15636 comp.unix.bsd:13560 Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!gatech!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.unix.programmer,comp.unix.bsd Subject: Re: Detecting dead client in BSD socket Date: 8 Mar 1994 22:51:32 GMT Organization: Weber State University, Ogden, UT Lines: 61 Message-ID: <2livhk$961@u.cc.utah.edu> References: <1994Mar3.154852.24090@il.us.swissbank.com> <2l92ia$hrd@u.cc.utah.edu> <1994Mar5.142417.28947@noao.edu> NNTP-Posting-Host: cs.weber.edu Keywords: socket bsd death In article <1994Mar5.142417.28947@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes: ]> Set SO_KEEPALIVE as an option and notification will be more immediate; be ]> sure and use select on the socket and check for exceptional conditions. ] ]Check for "readability" not an "exception" condition. If the other end ]dies, or dies and reboots, your socket will become readable after the ]keepalive probe(s) are sent; issue a read, and the error will probably ]be ETIMEDOUT or ECONNRESET. Check Chapter 23 of my recent book "TCP/IP ]Illustrated" for lots of information on keepalives. (This chapter is ]also reprinted in the Feb. 94 issue of Interop's ConneXions.) If you're ]going to use keepalives, you need to understand how they're implemented ]by TCP, regardless whether you use sockets or TLI. You're definitely right -- readability. But the read will return 0 characters read, not an error. This is critically bogus, in my opinion. On at least one implementation, you have to getmsg(0 to clear the error, or you are stuck with it (the Mentat 1.x implementation on VMS had this problem as well; I can't remember if I moved my hack over when we got the 2.0 stuff, or whether Mentat had fixed it themselves). ]> On the other hand, if it's a socket library on top of TLI and your UNIX ]> obeys the notification protocol, ] ]Socket libraries on systems such as SVR4 are *not* built on top of TLI. ]This is a fundamental misconception that is continually repeated. Sockets ]are built on top of TPI, the "Transport Provider Interface", a spec you ]can ftp from ftp.ui.org in pub/osi/tpi.ps. The socket library talks to ]TPI just like TLI does. Both require a special kernel streams module ]to help: sockmod and timod. (Rago correctly talks about this in Section ]12.3 of his book "UNIX System V Network Programming".) TLI may be "closer" ]to TPI than sockets (since they're both made to look OSI-ish) but to say ]that sockets in SVR4 are built on top is TLI is plain wrong. Luckily, this was not a misconception to which I fell prey, although I think you're wrong in generalizing it -- I believe the Wollongong implementation on NCR towers, Arete 1100's, and pre-Lachman SVR4 (SVR4.0.1) used a libsocket built on TLI, not TPI. But anyway, I did say "if". 8-). The other thing to note was that the guy came back and said he's running on Solaris, which does not properly implement T_DISCONNECT like it's supposed to, so notification is in the toilet for him anyway. ]> rewriting directly to TLI will let you ]> not only run on other protocol stacks (XNS, IPX, OSI, etc.), it will ]> provide disconnect notification. ] ]Ah, but protocol independence does have its price, doesn't it :-) Using ]sockets I can get or set the SO_KEEPALIVE option with 3 lines of code ](assignment, function call, error handling). Please show the equivalent ]TLI code. I am especially interested in your implementation of getsockopt() ]using TLI (not XTI). Can't send you the code -- my source license won't let me... but if you have an SVR4.0.1 source license, you can look at it too. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.