Re: [remote protocol] support for disabling packet acknowledgement

[Sandra Loosemore <sandra@codesourcery.com>]

Daniel Jacobowitz wrote:
> 
> [snip]
> 
> The result of this is that the acks become ambiguous in the presence
> of an unreliable or antagonistically delayed transport.  For instance,
> if GDB sends a memory write, the stub acks it, the stub replies with
> OK, and then GDB's ack is delayed.  Existing implementations of the
> protocol will resend the OK in this case, assuming the message was
> lost - from stub side that's indistinguishable from ack lost.  GDB's
> long-delayed ACK arrives on the stub at the same time the OK arrives
> at GDB.  GDB must ack again - it doesn't know whether the first ack
> ever made it through, and if it doesn't ack now then the stub might
> keep resending that OK until it gets through.  So now GDB sends an
> ack.  Simultaneously the stub sends a stop reply indicating that some
> other thread has stopped.  When it receives the ack, it thinks GDB saw
> the stop reply and does not resend it.  But GDB hasn't seen it yet,
> and if it is dropped the conversation is now out of sync.  GDB will
> hang around waiting for an event that has already been reported.

Thanks, Dan.  This is about the point at which my brain exploded.  :-P

My suggestion for dealing with the breakage was for the stub to send an 
out-of-band ^C back to GDB when it has something to report, rather than sending 
an actual stop reply asynchronously.  Then GDB could (synchronously) poll the 
stub with an "eh, what's up?" packet, the stub could reply, the normal +/- acks 
wouldn't be any more broken than they are now, the stub could resend the ^C 
without any possibility of confusion if it thought GDB hadn't gotten it the 
first time, etc.  I still think that's workable, but the reaction here was 
"let's not go there; let's just assume the connection is reliable".  I think 
everyone else's brain had exploded by that point as well.  ;-)

In any case, whether or not it ends up being a requirement for non-stop mode in 
the long run, being able to turn off the protocol acks seems useful on its own 
for reducing unnecessary round-trips when debugging over laggy TCP connections. 
  Did anyone have comments on the patch itself?

-Sandra