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)
Hi!
Good news: You don't need to do anything. MHD will maintain persistent
TCP connections and use TCP's flow control mechanisms automatically.
You can _force_ MHD to not keep connections open by adding "Connection:
Close" to your HTTP response header manually, but by default MHD will do
the righ
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 e
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 asy
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?
b.For asynchronous communication , i.e the application received the
request but is n
Hi Christian,
Thank you. Could you please explain how the TCP's flow control mechanism is
helping in this case. A few lines would be great, please.
thanks, santos
On Tue, Sep 18, 2018 at 3:18 PM Christian Grothoff
wrote:
> Hi!
>
> Good news: You don't need to do anything. MHD will maintain pe
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 comm
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
On 09/18/2018 02:22 PM, Kunal Ekawde wrote:
> 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
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
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 wrote:
> Thanks Christian.
>
> I have a question on "MHD_OPTION_CONNECTION_ME
On 09/18/2018 02:35 PM, Santos Das 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?
It does not directly translate.
On 09/18/2018 02:43 PM, Santos Das wrote:
> 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 ?
MHD uses "whatever is left" (minus some reserves depending on what phase
13 matches
Mail list logo
