This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Change stubs to handle '$' after packet start


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]