From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5074 invoked by alias); 19 Jan 2006 01:18:53 -0000 Received: (qmail 5066 invoked by uid 22791); 19 Jan 2006 01:18:52 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.203) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 19 Jan 2006 01:18:51 +0000 Received: by zproxy.gmail.com with SMTP id m22so98728nzf for ; Wed, 18 Jan 2006 17:18:50 -0800 (PST) Received: by 10.36.22.15 with SMTP id 15mr7385071nzv; Wed, 18 Jan 2006 17:18:50 -0800 (PST) Received: by 10.37.2.42 with HTTP; Wed, 18 Jan 2006 17:18:49 -0800 (PST) Message-ID: <8f2776cb0601181718ybb52db4pc5c3aca9bf00adfe@mail.gmail.com> Date: Thu, 19 Jan 2006 02:00:00 -0000 From: Jim Blandy To: gdb@sourceware.org Subject: Re: to_xfer_partial, qPart, and EOF In-Reply-To: <20060118231837.GA17726@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060118231837.GA17726@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00184.txt.bz2 On 1/18/06, Daniel Jacobowitz wrote: > I'm currently very well aware of the round trip latency in the remote > protocol; it makes a huge difference over TCP, where larger packets are > basically free up to a certain size, but round trips are very slow. At > the time he wanted to pursue this immediately; Andrew wanted to go without > it for the moment, and it was never revisited. > > So that's action item one; I think it's time to add this. So far so good. This, and a few other remote protocol wrinkles, are consequences of the mis-layering of the GDB protocol. The protocol should simply specify that the entire block of data gets transmitted, and let lower layers handle retransmission and fragmentation. I recognize it's probably not practical to fix this today, and maybe it never will be. But I keep running into instances of this when I work on the remote protocol --- tracepoint definition packets needing to be broken up into pieces to avoid long packets; breakpoint packets needing to be idempotent, because they might be retransmitted; and so on --- so I wanted to mention it. Perhaps someone will have a flash of super-coder powers some weekend. > Any comments on either of these plans? Otherwise I will probably impleme= nt > them in the next couple of days. I'm doing a lot of work in this area > at present. Sounds great to me.