This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: Change stubs to handle '$' after packet start
- To: Stan Shebs <shebs@cygnus.com>
- Subject: Re: Change stubs to handle '$' after packet start
- From: jtc@redback.com (J.T. Conklin)
- Date: 19 Aug 1999 20:04:42 -0700
- Cc: gdb-patches@sourceware.cygnus.com
- References: <199908200125.SAA04836@andros.cygnus.com>
- Reply-To: jtc@redback.com
jtc> This change adds code in getpacket() to start a new packet if
jtc> the packet start character ('$') is received while reading
jtc> the packet contents. This prevents the loss of the
jtc> subsequent packet if the packet end character '#' is
jtc> lost/garbled.
Stan> The change is innocuous, but is it really useful?
I think so. I suspect serial packet protocols which have both begin
and end packet characters do the same thing. I checked SL/IP, but
that only uses a single begin (or end, depending on your point of
view) character for packet framing.
Stan> If you're losing random chars out of packets, seems like it
Stan> would be better to let the user know, rather than trying to
Stan> struggle on with bogus data and dying within seconds anyway.
This change should greatly reduce the time necessary to recover in the
case where the end of packet character is lost or corrupted, or one of
the subsequent checksum characters are lost. It is not intended to
help situations where users are encountering large numbers of corrupt
packets. But rather cases where character loss or corruption is rare.
A example might help clarify the situation:
1) A packet is received where the end of packet character has been
corrupted.
$......&XX
2) GDB waits 'remote_timeout' seconds for an ACK, then retransmits
the packet.
3) The packet is received. Because the stub did not restart when the
begin packet character was received, it is appended to the partial
packet already in the buffer. If the length of the combined packet
is < BUFMAX, the checksum will (hopefully!) fail and the stub will
send a NAK, otherwise the stub will wait for the next begin packet
character.
$......&XX$......#XX
4) Even if the checksum failed, because GDB does not handle NAKs (you
might recall a patch I submitted and subsequent discussion on this
topic earlier this year), it waits another 'remote_timeout' seconds
then and retransmit the packet.
5) The packet is received successfully.
Because the packet was not restarted, it takes 2 * 'remote_timeout'
seconds to recover. If the user does not change the default value,
that's 40 seconds. This change cuts the wait in half.
I think your concern about continuing on with bogus data is unfounded.
The framing forbids either the packet begin or end characters from
occuring in the packet data. If a begin char is received, there is
nothing it could be but the begining of a new packet.
As for letting the user know something is wrong. Unfortunately, there
is no good way to indicate to the user that a stub is losing packets.
We could add a debug_error() call there on those stubs that support
that function. We could also add some standard statistics variables
that could be queried by GDB (number of packets received, number of
packets sent, number of retries, etc.). It would be easy enough to
add the same sorts of counters on the GDB side, which is almost the
same thing.
--jtc
--
J.T. Conklin
RedBack Networks