[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] What news on the Rialto? Recent work on gpsd.

From: Terje Mathisen
Subject: Re: [gpsd-dev] What news on the Rialto? Recent work on gpsd.
Date: Wed, 02 Oct 2013 13:29:28 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21

Eric S. Raymond wrote:
All but one of the handful of bugs previously lingering on the tracker
have been fixed and closed.  All pending patches have been merged or
rejected. In the process, I found and squashed a deep-seated bug in
the packet getter that I think explains several puzzlements, including
flakiness in handling TCP/IP GPS data sources and the report that
NTRIP was working over UDP but not TCP.

The bug was that in certain states the packet getter might lose sync
and close a device if the timing of writes from it was such that GPSD
saw a read end in the middle of what might be a valid packet -
that is, as opposed to being in ground state where no packet preamble
has been seen yet.

This never happens under UDP, because from UDP sources each datagram
is a full packet transmitted atomically. Serial writes over a USB or
RS-232 device from a GPS or AIS radio tend also to ship whole packets
at a time (or groups of whole packets) after buffering output
on-chip. Only in the TCP/IP case do network buffering effects
sometimes result in an atomic read boundary falling in the *middle* of
a packet transmission.

Eric, I would say that we've been very lucky if this issue hasn't caused a significant amount of dropped messages over RS232!

It is exactly analogous to the problem I had 30 years ago when writing terminal emulator code, I had to handle breaks in the serial straem at any point, including in the middle of long/complicated escape sequences.

At the time (MsDos, 1982++) my fix was to use a 16-bit state machine flag which effectively worked as a jump pointer back to the position the parser had gotten to on the last block of data.

It would have been much simpler to just reparse from the beginning of any such sequence until it was complete, but I didn't have the cpu cycles to spare for this. :-(

(OTOH, modern serial ports have at least 8-16 bytes of input buffers and tend to use delayed interrupts in order to reduce the overhead per byte, this would often allow short messages to pass through in a single iteration.)


- <address@hidden>
"almost all programming can be viewed as an exercise in caching"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]