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

[Terje Mathisen]

Eric S. Raymond wrote:
[snip]
> 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.)

Terje

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