From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21024 invoked by alias); 6 Nov 2007 18:31:05 -0000 Received: (qmail 21012 invoked by uid 22791); 6 Nov 2007 18:31:04 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Nov 2007 18:31:02 +0000 Received: (qmail 8075 invoked from network); 6 Nov 2007 18:31:00 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Nov 2007 18:31:00 -0000 To: Eli Zaretskii Cc: gdb-patches@sourceware.org, ukleinek@informatik.uni-freiburg.de Subject: Re: [rfa] Clarify remote protocol RLE example References: <20071103161956.GA7885@caradoc.them.org> <20071103191822.GA17820@caradoc.them.org> From: Jim Blandy Date: Tue, 06 Nov 2007 18:31:00 -0000 In-Reply-To: <20071103191822.GA17820@caradoc.them.org> (Daniel Jacobowitz's message of "Sat, 3 Nov 2007 15:18:22 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00097.txt.bz2 Daniel Jacobowitz 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.)