Re: [libmicrohttpd] Regarding Flow control

[Santos Das]

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 <address@hidden> 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 <address@hidden
> <mailto:address@hidden>> 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 <address@hidden
>     <mailto:address@hidden>
>     > <mailto:address@hidden <mailto:address@hidden>>> 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
>     <address@hidden <mailto:address@hidden>
>     >     <mailto:address@hidden <mailto:address@hidden>>>
>     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
>