libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Some issues with MHD


From: Olivier Delhomme
Subject: Re: [libmicrohttpd] Some issues with MHD
Date: Wed, 4 Nov 2015 22:49:51 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Christian,

On Tue, Nov 03, 2015 at 11:46:30PM +0100, Christian Grothoff wrote:
> Hi!
> 
> Ok, so I've solved most of the mystery.  SVN 36568 was indeed wrong, the

I'm the one having the shrinkage problem.

> pool reallocation was correct before 0.9.45 and will be again right in
> 0.9.46 (to be uploaded ASAP).  I now put a comment as to why it was OK
> to begin with.

As I investigated to answer here I realized that I changed my way of
handling my buffer in the same time of SVN 36568 and that this new way
is much less sensitive to the number of calls to MHD_AccessHandlerCallback
so SVN 36568 might not have solved the problem. The fact is that 0.9.46
have it.

> Eugenio: your 'strlen(line)' change is also in 0.9.46, as the code
> didn't tolerate "extra" empty lines in the protocol, but it is clearly
> better to not drop a connection just because between two requests there
> is an unexpected empty line. (Especially since the spec maybe unclear
> with respect to how many \r\n one should put at the end of a POST
> with/without a footer).  So that makes MHD more tolerant, which is a
> good thing (and harmless).
> 
> What I didn't quite figure out is why there is then still this
> buffer-shrinkage that motivated the SVN 36568-change to begin with: I
> went again over the code (now with more understanding), and couldn't
> find anything.  So for that, I would now really appreciate a test that
> demonstrates this.

I have a case with my program that does the shrinkage. My client is
transferring files with POST commands to server  libmicrohttpd
powered. In the case I have made, I'm transferring 3 files with a
buffer of 5 593 840 bytes:
ls -ls ~/tmp/
total 1219592
211968 -rw-r--r-- 1 dup dup 217055232 sept. 14 21:30 
void-live-x86_64-20150713.iso
550916 -rw-r--r-- 1 dup dup 564133888 sept. 19 22:17 
void-live-x86_64-20150713-mate.iso
456708 -rw-r--r-- 1 dup dup 467664896 nov.   2 22:11 
void-live-x86_64-musl-20151009-xfce.iso

I keep the size of the buffer, the number of times that my callback 
has been called and calculate the mean size of upload_data (the
mean value of *upload_size). You'll find a file with this content
here: http://src.delhomme.org/download/libmicrohttpd/cdpfglserver.2

I have made two graphs: one that shows the number of time the callback
is called (column 2): 
http://src.delhomme.org/download/libmicrohttpd/number_of_calls.png

And one that shows the mean value of *upload_size (column 3):
http://src.delhomme.org/download/libmicrohttpd/mean_upload_size.png

On that last one you can see the shrinkage happening in two ways:

1) The most visible one is the steps from around 13000 to around 
11000 and then around 9300 and then around 8100... It seems that
the time for the next shrinkage big step is divided by 2. Does
this means something to you ?

2) The shrinkage happens at every steps: when looking closely to
the graph you can see that before the first big step the mean size
goes from around 13100 to 13000. 

Regards,

Olivier.



> Anyway, happy hacking!
> 
> Christian
> 
> On 11/03/2015 07:08 PM, Eugenio Perez wrote:
> > Hi All.
> > 
> > First of all, congrats for this excellent library! I think it does
> > have a clear interface and it's very usable.
> > 
> > However, I have found two issues. I don't know if I'm using bad the
> > library, so please correct me if I'm wrong.
> > 
> > I'm trying to send, using one connection, a lot of small (~2K) POST
> > messages (in the real case, JSON text). If I use not chunked encoding
> > messages (i.e., specifying Content-Length header), all is OK.
> > 
> > However, I've found that if I try to send the messages in chunks, MHD
> > drops the connection, and the client needs to reconnect again. Testing
> > in deep, I've found that:
> > 
> > * If I increase MHD_OPTION_CONNECTION_MEMORY_LIMIT, the connections
> > are dropped slower (i.e., the same connection last longer).
> > * If I send smaller messages that the sent in http-post.c, MHD does not 
> > drop.
> > * If I change URL length, drops rate changes:
> >   * ./http-post "http://10.0.70.175:8080/aaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> > causes drops
> >   * ./http-post
> > "http://10.0.70.175:8080/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"; no drops
> > * If I apply the patch attached, MHD does not drop my connection
> > anymore. However, I don't know if it affects some other MHD internals.
> > 
> > All of this happens with MHD 0.9.44. I've seen that you just announced
> > 0.9.45. However, if I update is even worse: connections are being
> > dropped almost every packet or 2 packet! If I bisect, the commit that
> > introduce the issue is r36568 (with message "-fix assertion failure
> > from race on shutdown and buffer shrinkage with pipelining").
> > 
> > I attach client and server I'm using to test situation. In order to
> > detect reconnection, I just use:
> > 
> > tcpdump -nni any "port 8080 and tcp[tcpflags] & (tcp-syn) != 0"
> > 
> > Where 8080 is the post I'm using to testing.
> > 
> > Am I using the bad options? Is the patch valid to fix the issue? if
> > not, what could I do to keep debugging this?
> > 
> > Thanks and regards.
> > 
> 

-- 
"Quand la vérité n'est pas libre, la liberté n'est pas vraie."
                                             [Jacques Prévert]



reply via email to

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