Nicolas Williams writes: > Are there apps that want one more confidence than the first scenario > provides, but less than 100%? I don't know, but clearly they can make > do without support for the middle two scenarios.
Yes, I understood what you were getting at. The part that I don't see is why validating those middle two layers and getting "some" added reliability is really worth anyone's time. There are better ways to do this. For such a hypothetical application, a better way would be to introduce a timer-based unidirectional ack. The sender just does write(2) and forgets about it. Once every <timer-interval> seconds, the peer sends back an application-layer acknowledgment indicating the newest application (sender-specified) sequence number it has correctly processed. The sender can asynchronously read those application-level ack messages and record which bits have made it to the far end. This gets you complete reliability, no round-trip waiting, and arbitrarily low overhead, at the cost of some possible duplication (log replay) if a failure happens and you need to restart. No kernel hacks required. > > > 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. :-/ > > Since being compatible does not buy the app 100% confidence that the > peer app got the data we might as well lie to the app. I considered that, but didn't mention it because I figured it'd get roundly booed. The lie that I would prefer to return would be "0". -- 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]
