This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [remote protocol] support for disabling packet acknowledgement


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]