Thanks for prompt response, few more doubts :) 1. Yeah, timers per connection on each request doesn't seems good, need to figure that out. 2. When you say ' MHD won't use more RAM per connection than allowed by MEMORY_LIMIT' , will MHD read from TCP buffer only 'MEMORY_LIMIT' data ? is it the recv call buffer size ? when will remaining data be read ?
Thanks On Tue, Sep 18, 2018 at 4:37 PM Christian Grothoff <groth...@gnunet.org> wrote: > On 09/18/2018 12:23 PM, Kunal Ekawde wrote: > > Thanks Christian, > > So as a solution we need to have a timer for such cases and on timer > > expiry , resume the connection post which as data is not available, > > either error respond or close connection. > > Yes, basically if you suspend to perform some asynchronous activity that > needs a timeout, you need to manage that timeout. > > > If we close the connection, we > > shall loose the pending requests on that connection right ? > > Yes, if you "close" i.e. by returning "MHD_NO". > > > and if we > > error respond, we shall get pending messages on that connection right > > (number of pending messages would depend on > > MHD_OPTION_CONNECTION_MEMORY_LIMIT?)? > > If you respond, other requests on the connection will then be processed, > but not limited by the MEMORY_LIMIT. MHD won't use more RAM per > connection than allowed by MEMORY_LIMIT, but the OSes for client and > server negotiate a TCP buffer which is really what limits network > transmissions. And the client just won't be able to transmit more > requests than what that TCP buffer allows until you resume, but in > theory the number of requests that can be pipelined is unlimited. > > > If the case was client side disconnection, post resume, we should get > > notify callback with reason 'MHD_REQUEST_TERMINATED_WITH_ERROR' ? so we > > can do cleanup right ? > > Yes. > -- ~Kunal
