gpsd-users
[Top][All Lists]
Advanced

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

Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request"


From: Gary E. Miller
Subject: Re: [gpsd-users] gpsd as gpsd client, error "Unrecognized request"
Date: Thu, 7 Sep 2017 13:16:50 -0700

Yo Florian!

On Thu, 7 Sep 2017 10:04:11 +0200
Florian Petry <address@hidden> wrote:

> Is it still planned to merge this fix? We are running into the
> "Unrecognized request" problem frequently when connecting one gpsd to
> another with gpsd://...

What fix?  I see no fix.  I also see no way, in this email, to
reproduce the problem.  Please file an issue:



RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin


> 
> Regards
> 
> Am 28.06.2017 um 21:18 schrieb Larry Boyd:
> > This is a better fix for the server side.
> > The difference is that this one will give up after 10 seconds
> > rather than getting stuck forever.
> >
> > Although this is unlikely to make anything worse (unlike previous
> > version), I'm not sure that it is optimal, and frankly, I don't
> > understand the use of the protocol well enough (yet) to decide how
> > it should be adjusted, if at all.
> > For instance, I am using the number of bytes read as the mechanism
> > for determining if the entire request has been read, and I'm using
> > 1 byte as the threshold. What happens if the request is 100 bytes
> > long and we read 17 bytes? How can we tell that we have read to the
> > end of the entire request? Does a request always terminate with
> > '\r' or '\r\n'? I'm not sure if it does or not, and frankly, it may
> > depend on the implementation of the client. The two lines
> > immediately following the bulk of this patch suggest that requests
> > may not always end in '\n'.
> >
> > If someone can say for certain that a request will *always* have a
> > '\r' in the last or second-to-last byte, then ideally, we could
> > read until we find that byte, and then continue.
> >  
> 
>
> 
> ingenieur
> wissenschaften
> htw saar
> 
> Hochschule für Technik und Wirtschaft des Saarlandes
> University of Applied Sciences
> 
> Fakultät für Ingenieurwissenschaften
> School of Engineering
> 
> Florian Petry, M.Sc.
> Forschungsgruppe Verkehrstelematik (FGVT)
> 
> InnovationsCampus Saar
> Altenkesseler Strasse 17/D2
> 66115 Saarbruecken
> Germany
> 
> +49 681 5867-648
> address@hidden
> http://www.htwsaar.de
> https://fgvt.htwsaar.de
> 
> 
> 


Attachment: pgp3QJOfe0WoJ.pgp
Description: OpenPGP digital signature


reply via email to

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