On Fri, Apr 28, 2006 at 05:36:36PM -0400, James Carlson wrote: > Nicolas Williams writes: > > 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. ;-}
I'm positing an application where robustness doesn't matter, but recovery is expensive enough that you want some confidence that the data made it, but you also care enough about latency that you're willing to settle for less than 100% confidence. Assign a probability that the data will make it to these scenarios: - the data was written to a socket - the data was written to a socket and put on the wire - the data was written to a socket and put on the wire and ACKed by the peer at the *ULP layer* - the data was written to a socket and put on the wire and ACKed by the peer at the *application layer* These are, intuitively, in order of increasing probability, with the last one having a probability of 1. 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. > > 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. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
