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

[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.

fix_request_split_server_v2.patch
Description: Text Data