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. If we close the connection, we shall loose the pending requests on that connection right ? 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 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 ?
Thanks, Kunal On Tue, Sep 18, 2018 at 3:12 PM Christian Grothoff <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>> 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>> 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 > -- ~Kunal
