Re: [libmicrohttpd] feature request: get connection_timeout value from MHD_Connection structure

[Evgeny Grin]

On 15.03.2017 13:35, Vitaliy T wrote:
> On 15 March 2017 at 12:58, Evgeny Grin <address@hidden> wrote:
>> Why do you want to play with timeout during connection suspend?
>> Function description explicitly state:
>> "Suspended connections will NOT time out; timeouts will restart when the
>> connection handling is resumed."
> 
> That's right. This is why after resuming a connection and if it is
> timed outed because the MHD thinks so.

Sorry, didn't get the idea.
If you resume connection - it timeout timer will be restarted. So, right
after resume connection should not timeout.
Please, clarify - what you expect and what you get.


> There is only one place where MHD send the INTERNAL_ERROR message:
> 
> src/microhttpd/connection.c
> 
>      1358 static void
>      1359 MHD_connection_update_event_loop_info (struct MHD_Connection
> *connection)
>      1360 {
>      1361   while (1)
>      1362     {
> ...
>      1408         case MHD_CONNECTION_CONTINUE_SENT:
>      1409           if (connection->read_buffer_offset ==
> connection->read_buffer_size)
>      1410             {
>      1411               if ((MHD_YES != try_grow_read_buffer (connection)) &&
>      1412                   (0 != (connection->daemon->options &
>      1413                          MHD_USE_INTERNAL_POLLING_THREAD)))
>      1414                 {
>      1415                   /* failed to grow the read buffer, and the
>      1416                      client which is supposed to handle the
>      1417                      received data in a *blocking* fashion
>      1418                      (in this mode) did not handle the data as
>      1419                      it was supposed to!
>      1420                      => we would either have to do busy-waiting
>      1421                      (on the client, which would likely fail),
>      1422                      or if we do nothing, we would just timeout
>      1423                      on the connection (if a timeout is even
>      1424                      set!).
>      1425                      Solution: we kill the connection with an error 
> */
>      1426                   transmit_error_response (connection,
>      1427
> MHD_HTTP_INTERNAL_SERVER_ERROR,
>      1428                                            INTERNAL_ERROR);
>      1429                   continue;
>      1430                 }
>      1431             }
> 
> A TCP connection might be active and clients are waiting for
> responses. But MHD thinks its smarter then a man :) No offend.

Correct, sometimes machine may give you idea if you missed something.
In this case internal read buffer is overflown because application
didn't process received data.

>> Could you describe in details: what do you want to get, how did you
>> start MHD and what is not working?
> 
> The idea is that the server is able to handle only one POST (upload
> file) request per a time from clients. Others clients are suspended
> when there is at least one active upload.

Why not to limit number of connection to 1 by
MHD_OPTION_CONNECTION_LIMIT? Then you will process single connection
only at any time.
To force close connection after response, add "Connection: close" header.


> Suspending/resuming is a practical recommended by the Reference Manual.
> 
> I want to suspend a connection by some amount of time which may vary
> per a program basis. Current implementation sets timeout to 0 before
> suspending the connection. Otherwise, as I said previously, in case if
> the connection is timed out, then MHD will send a response with the
> hardcoded text above.

Mentioned response is not related to resume/suspend or timeout.
Application didn't process received data by callback and internal buffer
overflown.

Why do you need to set timeout before suspend?
You can suspend connection for any period of time, timeout do nothing
with suspend/resume.

> 
> Setting the connection timeout to 0 leads to problems for clients:
> 1. They just closing a connection by its own timeout value.
> 2. The server might have time to send response to a suspended client if
> 
> Why I want to get/set connection timeout per a connection basis?
> 
> 1. Because, it is simpler then writing more code than the task requires.
> 2. Because there is a function to set connection timeout and none to
> get one's value.
> 
> I can implement the get function in my program easily. I just asked
> for a feature request. If you see that is useless, then ok, just say
> so. I will not be disappointed much.

Sorry, didn't noticed a feature request. I saw only concrete patch,
which do not follow MHD rules.
And you are right, you can implement very easy this in your application.
You have pointer associated with each connection. You can put any
information you want to structure pointer with this pointer.


> I suppose we may close the question in the next way. I will implement
> everything as I want, e.g. will made local patch to MHD and will test
> within some kind amount of time (weeks, months). And in the case if I
> would like see this feature in MHD-core I will send a patch.
> 
> Ok?

Patches are always welcome. If you improve MHD functionality and don't
break anything - we will merge it.

> 
>> In one thread you are asking about external polling, in another - about
>> timeout and suspend/resume. Are those questions connected or independent
>> situations?
> 
> I am working on one MHD project at the moment. All questions are
> connected with each other.
> There is a strong connection between suspend/resume and a connection
> timeout, see above.

Sorry, still unclear for me, why do you need custom timeout connected
with suspend/resume. And what is not working.

-- 
Best Wishes,
Evgeny Grin