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?" For the latency issue, the application response can be piggybacked on the ack, reducing the latency to zero. If it's not piggybacked, then you really don't have any guarantee (from merely the TCP ack) that the application has that message "in memory." And if you're worried about HA things, the application could abend after TCP acks but before the application reads, so it seems to me that there's no necessary or sufficient information available in looking at the TCP ack numbers alone. Those only show that the peer's TCP module has the data, not that the data have gone anywhere useful yet. Note that such a TIOCOUTQ mechanism will *NOT* tell you whether that remote application has started running behind, because it's really giving you the TCP behavioral artifacts instead. If that application is in trouble for some reason (say, stuck on a failing disk I/O for some prior transaction), then knowing that TCP has acked the data doesn't tell you at all that the remote application is "working" on the transaction. At best, you could get some sort of TCP-level pseudo-synchronization, but it's quite unclear to me why this would ever really be helpful. > Note that any asynchronous stream socket send implementation will need > essentially the same mechanism. I'm still not seeing it. The one usage I could imagine here would be with some sort of adaptive codec that's able to increase its compression effort as the local send queue backs up. But even with such a hypothetical application, you'd likely be better off doing longer-term application level round-trip estimations and smoothing the behavior so that the user doesn't end up with oscillatory behavior and some dramatically poor results. -- 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]
