On Fri, Apr 28, 2006 at 04:31:55PM -0400, James Carlson wrote: > Bart Smaalders writes: > > Once both machines have copies in memory, both machines can > > process the transaction and then compare the results at the end. > > Note that the artificial requirement is that the requested transaction > > is stored in memory on at least two separate machines in different > > locations. > > > > Yes, this can be done w/ an explicit ACK from the application, at > > some additional number of micro/milliseconds latency. > > 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. 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. Another type of application where it might do would be one where you can recover from one peer never getting the message, but recovery is slow enough that you have an incentive to try to make sure that the data makes it to your peer, while latency is an incentive to not try too hard. I don't see this as a terribly important feature. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
