Re: [rfa] Clarify remote protocol RLE example

[Jim Blandy <jimb at codesourcery dot com>]

Daniel Jacobowitz <drow at false.org> writes:
> On Sat, Nov 03, 2007 at 09:01:21PM +0200, Eli Zaretskii wrote:
>>  Response @var{data} can be run-length encoded to save space.
>>  Run-length encoding replaces runs of identical characters with the
>>  character @samp{*} followed by a repeat count.
>
> How about "with an initial character, the character @samp{*}, and a
> repeat count"?  With that, I quite like your version.
>
>> >  The printable
>> >  characters @samp{$}, @samp{#}, @samp{+} and @samp{-} or with a numeric
>> >  value greater than 126 should not be used.
>> 
>> This part I simply don't understand.  What does it mean ``should not
>> be used''? what should be done instead? break the string into several
>> smaller ones?
>
> May not be used (they have special syntactical meaning in the
> protocol).  So you need to stop the RLE string one character earlier,
> e.g.:
>
>   {0}		0
>   {00}		00
>   {000}		000
>   {0* }		0000
>   {0*!}		00000
>   {0*"}		000000
>   {0*"0}	0000000
>   {0*"00}	00000000
>   {0*%}		000000000
>
> Rereading this, and looking at my notes in gdbserver, I don't think
> there is any point to the restriction on + or -.  They're the protocol
> ack and nack characters, but they can already appear elsewhere in
> responses.  Jim, do you see any reason they should be forbidden?

You're obviously right that the question is, "Should + and - be
permitted in packet bodies at all", not "are they permissible RLE
length characters".

If GDB sends a packet, and the stub sends an ACK and then a packet
that contains a +, but the ACK is garbled or dropped, GDB will skip
characters until it sees the + and then take that as the ACK.  Then
GDB will wait for the response which the stub has already sent, time
out, and retransmit the request.

However, if the packet doesn't contain a +, the consequence of the
missed ACK is a timeout anyway.

If GDB mistakes a packet body character for a NACK, it could
retransmit a request that the stub has carried out.  But we already
know that the protocol has no protection against retransmission, so
this is not a new bug.

So I don't think it makes any difference whether packets contain
ACK/NACK characters.

(I hereby express my resolution never to design a protocol that sends
acknowledgements outside checksummed frames.)