Thanks Christian. Looks like you answered this question for Kunal Ekwade already. Thank you.
But, still not clear from your reply, is it equal to the receive buffer size ? On Tue, Sep 18, 2018 at 6:05 PM Santos Das <santos....@gmail.com> wrote: > Thanks Christian. > > I have a question on "MHD_OPTION_CONNECTION_MEMORY_LIMIT" . I went through > the manual. How does this affect the send/recv buffer size per client > connection. What does it eventually translate to? > > MHD_OPTION_CONNECTION_MEMORY_LIMIT - Maximum memory size per connection > (followed by a size_t). The default is 32 kB (32*1024 bytes) as defined by > the internal constant MHD_ > POOL_SIZE_DEFAULT. Values above 128k are unlikely to result in much > benefit, as half of the memory will be typically used for IO, and TCP > buffers are unlikely to support window sizes above 64k on most systems. > > On Tue, Sep 18, 2018 at 5:28 PM Christian Grothoff <groth...@gnunet.org> > wrote: > >> On 09/18/2018 01:31 PM, Santos Das wrote: >> > Hi Christian, >> > >> > Thanks a lot. I have few questions in this regard - >> > >> > a. When we put the connection in suspend state, can we pass a timeout >> > at the expiry of which the connection will be automatically resumed? >> >> No. >> >> > b. For asynchronous communication , i.e the application received the >> > request but is not able to send the response now (it needs to do some >> > work may be creating another request to another endpoint) , is it >> > mandatory to use suspend-resume only or there is some other mechanism >> > that we can use ? >> >> If you use 'thread per connection', you could also simply block. >> >> > c. How does the keep alive works in the HTTP server library ? >> >> MHD takes care of it, it adds keep-alive headers and processes them >> _unless_ explicitly overridden by the application. >> >> > Could you please explain how the TCP's flow control mechanism is >> > helping in this case. A few lines would be great, please. >> >> TCP flow control requires the kernel to provide message buffers for >> retransmission (sender) and reordering (receiver). So those buffers can >> and will be used by the kernel (on any OS) if the client sends >> additional requests that the server is not yet processing. >> >> > Sorry, lot of questions. But, please see if you could help in this. >> > >> > On Tue, Sep 18, 2018 at 3:12 PM Christian Grothoff <groth...@gnunet.org >> > <mailto:groth...@gnunet.org>> wrote: >> > >> > If you suspend a connection, you are responsible to schedule some >> job to >> > resume it, after which MHD's timeout counter will start again (and >> of >> > course your response logic could then also just force MHD to close >> the >> > connection once MHD asks for response data). MHD timeouts are >> there to >> > detect (idle) clients that just keep connections open, not to >> prevent >> > the server from suspending a connection. >> > >> > If the client closes a connection, it'll be detected if/when we try >> to >> > send data to the client and handled appropriately. >> > >> > Happy hacking! >> > >> > Christian >> > >> > On 09/17/2018 09:01 PM, Kunal Ekawde wrote: >> > > If the connection is suspended and cases of: >> > > a. client closes the connection before response is sent. >> > > b. server app doesn't respond at all post suspend. >> > > >> > > both cases there is no notification by MHD even if connection >> > timeout is >> > > specified and notify callback. How can these cases be handled ? >> > > >> > > Thanks, >> > > Kunal >> > > >> > > On Mon, Sep 17, 2018 at 9:02 PM Santos Das <santos....@gmail.com >> > <mailto:santos....@gmail.com> >> > > <mailto:santos....@gmail.com <mailto:santos....@gmail.com>>> >> wrote: >> > > >> > > Hi, >> > > >> > > Just to add more, my application is single threaded and I am >> > running >> > > MHD inside that. I don't create additional threads. I use >> suspend >> > > and resume as suggested earlier as I do async processing. >> > > >> > > So, I am thinking how can we implement flow control in this >> > scenario.. >> > > >> > > Thanks, Santos >> > > >> > > >> > > >> > > On Mon, Sep 17, 2018 at 8:22 PM Santos Das >> > <santos....@gmail.com <mailto:santos....@gmail.com> >> > > <mailto:santos....@gmail.com <mailto:santos....@gmail.com>>> >> > wrote: >> > > >> > > Hi, >> > > >> > > Could you kindly let me know how can we implement the flow >> > > control ? Protection against the badly behaving clients. >> > > >> > > >> > > HTTP/1.1 servers SHOULD maintain persistent connections >> > and use TCP's flow control >> > > >> > > mechanisms to resolve temporary overloads, rather than >> > terminating connections with >> > > >> > > the expectation that clients will retry. The latter >> > technique can exacerbate network >> > > >> > > congestion. >> > > >> > > >> > > >> > > https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html >> > > >> > > >> > > Thanks, Santos >> > > >> > > >> > > >> > > >> > > -- >> > > ~Kunal >> > >> >
