Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!odin!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.protocols.tcp-ip Subject: Re: timimg-out a socket read Message-ID: Date: 28 Jun 90 09:55:24 GMT References: Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 44 In-reply-to: ihsan@ficc.ferranti.com's message of 25 Jun 90 03:34:14 GMT In article ihsan@ficc.ferranti.com (jaleel ihsan) writes: I am trying to use tcp-ip for real-time application. The application consists of a client in the field that collects real-time data every two seconds and sends it to the server which stores it in the database. [ ... ] The specification requires that if no data is received within 15 seconds, I declare the real-time data channel dead. This is a fuzzy specification. What do you mean by "received"? If all you mean is "data present at the socket" you can just time out the select(2) call. If you mean "connection still alive" things are different, but I cannot believe it... I do not know of any other means of timing-out the read except to use the keep socket "warm" option, [ ... ] But this is something that has to do with the lower level protocols. You want to check for the presence of *application* "data", I understand, not whether the other side of the connection is still keeping open the virtual circuit. The keepalive timeout has to do with whether the TCP circuit is still there, not whether there is any data on it, really. Of course if the circuit is dropped by the other side you assume that data will not be forthcoming, but then the converse is not true. Knowing that the circuit is still there (kind of carrier detect) will not help you determine whether it is still being used... Did I choose the wrong vendor, or did I made a mistake in choosing tcp-ip for real-time application ? (8=:|) I believe that you chose the wrong protocol. I reckon that for real time work the default should be UDP, not TCP. I do not really think that you need reliable, ordered virtual circuits, especially if the data you deal with is, as in most real time monitoring applications, perishable and time stamped. I think that for sampling/monitoring unreliable and connectionless is better, and lower overhead. Hey, even NFS uses it. Hey, they even use UDP for real time speech transmission... -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk