Chris Blackburn <[email protected]> writes: > One of these devices appears to rolled their own implementation of the > client rather than use an off the shelf library. As a result they had a bug > where they did not read from the TCP socket properly and after about 60 > seconds or so they had filled up their TCP receive buffer and were sending > back "TCP Zero Window" messages back to GPSD. This is obviously broken and > we will be getting them to fix their implementation. > > *however*, The strange behaviour we noticed was that, when this happened, > it killed GPSD for every client simultaneously. Nobody got JSON data until > this offending client eventually times out and reset its connection. At > which point, all of the other clients would get a burst of data. Then the > offending device reconnected and the saga repeated itself. So, one faulty > client caused all clients to get (effectively) no location data.
Totally out on a limb here, but with well-behaved clients, or one client, the server might just call write and not expect the socket to back up, and thus block. I would find and read the code. To fix, I would consider explicit socket buffer sizes, and then setting non-blocking IO, and if a socket gets EWOULDBLOCK, just force-disconnect it, logging of course. You could add in-gpsd buffers but that just lets you save more when things go badly. It might not help and it's a lot of complexity and opportunity for bugs.
