Hi David,
On Tue, Nov 16, 2010 at 12:15:01PM +0000, David Woodhouse wrote:
> When we get part of a TCP response, we currently busy-wait until the
> rest of the response arrives. Bad Sameo; no biscuit.
Now I know that it takes a busy loop for getting patches from you ;)
> We *also* busy-wait for ever if the server closes the TCP connection
> without giving us all the data we were expecting. In that case, recv()
> returns zero and we just sit in our loop repeating the call over and
> over again.
>
> We were also failing to handle a closed connection or short read when
> looking for the 2-byte length header.
>
> This untested patch should fix all this. In the very unlikely case of a
> short read on the initial 2-byte header, we do will still end up
> busy-waiting for the second byte — but that's still better than what we
> were doing before, when we'd busy-wait *and* discard the first byte.
> And, in fact, we would busy-wait for ever there was any kind of error on
> the socket during that header read.
>
> It might make sense to discard a partial response which gets truncated
> due to an error, rather than returning what we have managed to receive.
> A full response might come in from a different server. Or a better
> option might be to keep the *longest* of the partial responses for a
> given request, and feed that back to the client if all servers fail to
> give us a full reply. I've left the behaviour as it was for now.
Thanks a lot for the patch. It wasn't working at first, mostly due to the
following:
> + while (reply->received < reply->len) {
> + bytes_recv = recv(sk, reply + reply->received,
> + reply->len - reply->received, 0);
You want to recv your bytes on reply->buf, not reply.
I fixed that, and applied the patch, thanks again.
Btw, you're on the AUTHORS file now too.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
