Nicolas Williams writes: > > I must be missing something. Where does any additional latency come > > into it? And what precise bounds are you placing on "in memory?" > > As you pointed out before, having apps react to ULP ACKs instead of > application layer ACKs is not robust -- the peer could crash before > processing the ACKed data, for example, or could take forever to do it. > > But if you don't care that much then relying on ULP ACKs would certainly > mean lower latency than relying on application ACKs.
Not necessarly. First of all, TIOCOUTQ is strictly a polling interface. All you can do is read "instantaneous" (meaning really: some point in the recent past) queue depth. There's no way to wait for any particular octet acknowledgment. You must call it, wait a while, call it again, wait some more, and so on. So, the best you can do here with the requested interface is bounded by the shortest sleep time you can muster. But things are even less clear than that, due to delayed acks and piggybacking. A delayed ack means that TIOCOUTQ will report that the data haven't been acked yet, even though they've actually been received for quite some time. Again, that can add considerably to "latency," and benefits not at all from looking at the transport alone. > I could see applications for this, namely logging, where you want some > degree of robustness less than knowing that the data logged has been > committed to the log, but more than knowing that the data has been > written to a socket. Fuzzy robustness, I guess; I prefer binary > robustness, but hey, for some applications fuzzy might do. I think you've temporarily lost me there. ;-} Fuzzy robustness sounds little different to me from just calling write(2) and forgetting about it. The extra effort to grovel about in TCP detailed behavior doesn't buy real robustness, so why even bother? > I don't see this as a terribly important feature. Indeed. I'm with you there. The only reason we might want something like this is to be "compatible" with Linux. In the same sense that if all your friends have just jumped off a bridge, you might as well, too. :-/ -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
