Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!ames!excelan!donp From: donp@na.excelan.com (don provan) Newsgroups: comp.protocols.tcp-ip Subject: Re: timimg-out a socket read Message-ID: <1475@excelan.COM> Date: 27 Jun 90 23:39:34 GMT References: Sender: news@excelan.COM Reply-To: donp@Novell.com (don provan) Organization: Novell, Inc., San Jose, California Lines: 25 In article ihsan@ficc.ferranti.com (jaleel ihsan) writes: > >The specification requires that if no data is received within 15 seconds, >I declare the real-time data channel dead. > >I do not know of any other means of timing-out the read except to use the >keep socket "warm" option... Using keep-alives to keep the socket "warm" only insures that the remote device is still handling TCP traffic. It does not insure that the remote device is actually sending data. If it's possible for the device to continue to maintain the TCP connection while not sending any data, keep-alives and the associated timers will do you no good at all. This is yet another reason to avoid depending on TCP to provide this timeout and, instead, use your own timer to regain control and handle the error condition outside of TCP. Generally i find it's a bad idea to try to use TCP as a timing mechanism. TCP, being the good general purpose transport protocol it is, really can't anticipate how long an application is willing to wait under any given condition. It's better for the application to handle such things itself, particularly in a case like this where the desired timeout condition is so specific. don provan donp@novell.com