[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Feature request: Support for testing a connection's

From: Christian Grothoff
Subject: Re: [libmicrohttpd] Feature request: Support for testing a connection's status from a callback function
Date: Tue, 9 Feb 2010 20:43:50 +0100
User-agent: KMail/1.12.4 (Linux/2.6.31-14-generic; KDE/4.3.4; i686; ; )

On Tuesday 09 February 2010 05:52:51 pm Jesse Anderton wrote:
> I would like to implement something like a push request from my web server.
>  My underlying need is for my web server to be able to report to a client
> when particular events have occurred.  I am planning to implement this by
> providing a request which will remain idle and leave the connection open
> until it has something to report.  Once it has something to say, it will
> build and send a response containing all the events it has to report.  The
> client will process the events and then make a new request for any further
> events which are generated.
> It's already possible to write this request with libmicrohttpd.  This
> approach has a problem, though: we're sitting in a callback method for
>  quite a long time, and I know of no way to test whether the connection is
>  still valid.  I would like to be able to give up on the request if the
>  client closes the connection.
> Is it already possible to ask the library whether the connection is still
> active?  If not, is this something you would consider adding?

Hmm.  In principle yes, but the question here is what the best design would 
be.  I'm thinking that in the case where you do set a timeout for connections, 
that should already be taken care of (if not, that'd be a bug, I doubt we have 
a test for it).  In the case where the per-connection timeout is large and the 
client disconnects while the response callback is blocked, we have to consider 
two subcases:

1) external select: MHD should notice the disconnect in the next iteration and 
clean up automatically; no API should be required.  Now, this of course 
assumes that MHD checks for "already closed by client" in this case (which I'm 
again not sure it does), but I'd certainly take a good patch that would 
address this (if there is something to be done). 

2) thread-per-connection: here the callback is blocked purely in application-
code and we clearly would need some API to enable the application logic to 
check for client disconnects (since MHD does not run, it can't check itself 
directly).   An extra value in the enum MHD_ConnectionInfoType and returning 
the "is still connected" information from MHD_get_connection_info in the 
"union MHD_ConnectionInfo" would be my current preference for enabling this. 
Given that W32 uses 'HANDLE' and POSIX 'int' for sockets, I think we should 
limit the information returned to the specific bit required ('still 
connected?') instead of exposing the underlying network descriptor.

Testcases for any of these would also make me rather happy (and may motivate 
me to fix issues / limitations that they demonstrate).  

My 2 cents, further suggestions (and patches!!!) are always welcome.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]