From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27883 invoked by alias); 10 Jul 2008 19:59:35 -0000 Received: (qmail 27865 invoked by uid 22791); 10 Jul 2008 19:59:34 -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; Thu, 10 Jul 2008 19:59:17 +0000 Received: (qmail 17419 invoked from network); 10 Jul 2008 19:59:15 -0000 Received: from unknown (HELO bullfrog.localdomain) (sandra@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Jul 2008 19:59:15 -0000 Message-ID: <48766999.6070001@codesourcery.com> Date: Thu, 10 Jul 2008 19:59:00 -0000 From: Sandra Loosemore User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Paul Koning CC: gdb@sourceware.org, gdb-patches@sourceware.org, pedro@codesourcery.com Subject: Re: [remote protocol] support for disabling packet acknowledgement References: <48765B8A.6080805@codesourcery.com> <18550.24158.544203.163257@gargle.gargle.HOWL> In-Reply-To: <18550.24158.544203.163257@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2008-07/txt/msg00162.txt.bz2 Paul Koning wrote: >>>>>> "Sandra" == Sandra Loosemore writes: > > Sandra> You'll note the documentation says turning off acks may be > Sandra> desirable to reduce communication overhead *or* "for other > Sandra> reasons". In fact, it is the "other reasons" that motivated > Sandra> this patch. We are working on designing the extensions to > Sandra> the remote protocol to support nonstop mode, and we realized > Sandra> that we simply cannot do it in combination with using +/- > Sandra> acks on the asynchronous responses. If we need a reliable > Sandra> transport layer to support nonstop mode, we might as well > Sandra> turn the acks off completely instead of dealing with the > Sandra> extra complexity of trying to design the nonstop protocol > Sandra> around them. > > Ok, so does that mean the nonstop mode features won't work unless the > remote protocol is layered on TCP? Given that a lot of the time the > remote link is simply a UART serial link, is there an issue here? Probably so, but the +/- acks are not the way to solve it. :-( Our internal discussion on that issue was getting more and more complicated, to the point where I could not even follow what the exact problem was. My imperfect understanding is this: In nonstop mode, stop replies are sent asynchronously, which breaks the back-and-forth, GDB-talks-stub-responds model. The stub may send a stop reply when GDB is not expecting to read a regular packet response. With some care, we could interleave the protocol acks of these responses with the acks of the regular synchronous responses.... except if a response or its ACK got lost entirely in transmission. We got to the point of considering whether we needed to add some out-of-band protocol to support the asynchronous responses from the stub, mirroring the asynchronous ^C that GDB can send to the stub, for instance, before deciding we didn't want to go there right now. There's current practice (the existing Apple implementation) to support disabling +/- acks and it seems useful as a performance hack for TCP connections independently of the nonstop extensions, so why not formalize it? -Sandra