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: [email protected] [mailto:[email protected]] Im Auftrag von Christian Grothoff Gesendet: Donnerstag, 7. April 2016 18:44 An: [email protected] 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).
