Re: [libmicrohttpd] No response to client.

[Martin Bonner]

Firstly, apologies for the crappy formatting.  Any guesses which mail client 
I'm using?  (I
really need to find a version of QuoteFix that works in Outlook 2013.)
 
> First thing I'd want to just know is which threading mode you are using 
> (threads? epoll? select? 
> poll? thread-pool?). 

Does MHD_USE_THREAD_PER_CONNECTION answer that question?  If not, how do I tell 
the answer.

> Then I'd add 'strace', specifically checking when (and how much) MHD read()s
> data from the socket and/or when select/epoll unblock (if applicable).

Good call.  I keep forgetting strace.  (This is going to generate a *LOT* of 
data).

One additional tid-bit is that the client was originally waiting 500ms to 
finish sending the 
message, and 2000ms for the reply to come back.  Overnight, I ran with a 60s 
wait for both, and
I don't seem to have had any failures.  

It looks like I may just be being impatient - on the other hand, this ties in 
with the upload
I mentioned just hanging for an extended period.  Possible causes:  
libmicrohttpd gets itself
in a state where some timeout has to expire before it notices data;  my 
processor is locking up
for some reason (but a colleague finds that raising the priority doesn't help); 
my webserver
code is broken in some way.  (At this point, I doubt the problem is the client 
- the upload
is being done by Chrome, and the command is being sent by my hand-written 
client.)

I'll report back with further analysis.


-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von Christian Grothoff
Gesendet: Donnerstag, 7. April 2016 18:44
An: address@hidden
Betreff: Re: [libmicrohttpd] No response to client.

On 04/07/2016 03:53 PM, Martin Bonner wrote:
> I have an embedded webserver written with libmicrohttpd.  A client is posting 
> messages to it
> with custom crafted TCP send/recv calls (so not libcurl or anything trusted 
> like that).  In
> real life, these messages are sent every half a second.  Every so often 
> (about one in 3000 calls),
> the client doesn't receive a response.
> 
> I have simplified the code, reduced the delays, and increased the 
> logging.  I now get a message every millisecond or so.  The bad news 
> is that the failure seems to happen with a similar real time 
> frequency.  The message I am sending is quite short (TTMCOMMAND: 
> {"command":"ping"}), and usually the AccessHandler callback gets all 
> the data in one byte.  Occasionally however it gets split up into two 
> chunks.  (That is not a problem, I handle it correctly, but it might 
> be clue as to what is going on.)
> 
> The one time I have seen a failure on the debug code, the first 
> AccessHandler occurred as usual, but the second call (which actually 
> gets passed the upload data) didn't happen until the client timed out, and 
> created a new
> connection, and sent a new command to the webserver.  Looking at the logs, I 
> *don't* see
> that happen in the real case (the AccessHandler just never seems to occur).
> 
> Let me be clear: It is unlikely that the problem is in libmicrohttpd - 
> it is much more likely to be in the client (which might not be sending quite 
> valid HTTP
> commands), or in my code (which is making invalid assumptions).
> 
> I am using version 0.9.42 (I've checked the changelog - this doesn't seem to 
> be a fixed problem).
> 
> Any clue what I am doing wrong ? Alternatively, what additional logging would 
> be helpful? 

First thing I'd want to just know is which threading mode you are using 
(threads? epoll? select? poll? thread-pool?).  Then I'd add 'strace', 
specifically checking when (and how much) MHD read()s data from the socket 
and/or when select/epoll unblock (if applicable).