Re: [libmicrohttpd] Connection not represented by a file descriptor

[Tomas Heran]

Tomas Heran wrote:
> Hello,
>
> this is just a polite reminder that I'd really like to get your opinion
> on implementing connections like I described below.
>
> Thanks you,
> Tomas
>
> On 04 Jul 2014, at 16:25, Tomas Heran<address@hidden>  wrote:
>
> > Hello.
> >
> > I've recently started evaluating libmicrohttpd for purposes of my
> > project and while I like very much what I've seen so far there are
> > specific requirements imposed by my execution environment which
> > make integrating MHD HTTP server a little challenging.
> >
> > Namely:
> >
> > - The program handles its connections independently from MHD (listening,
> >   accepting new client connections and spawning threads to handle the
> >   client connections, etc.)
> >
> > - The connections are presented to the rest of the program as
> >   "objects", i.e. structures containing file descriptors which
> >   are not accessible from the client handling code (furthermore,
> >   even if the low-level fds were accessible, they aren't always
> >   sockets)
> >
> > If I eventually decided to use MHD for my project, I'd have to
> > introduce to MHD a special kind of connection that is represented by a
> > set of functions for reading, writing, selecting/polling, closing etc.
> > and an "ID" to be able to find the particular "stream" that the
> > functions need to operate on.
> >
> > While understanding this may be very specific to my project and not too
> > interesting for many others, I'd still like to know whether you'd be
> > interested in accepting a patch that implements such kind of
> > connections? My intention would be to work with the community to
> > introduce a suitably generic/abstract representation that would
> > maximize re-use for other similar use cases.
> >
> > Please let me know.
> >
> > Thank you,
> > Tomas Heran
Tomas Heran wrote:
>
> Hello,
>
> this is just a polite reminder that I'd really like to get your opinion
> on implementing connections like I described below.
>
> Thanks you,
> Tomas
>
> On 04 Jul 2014, at 16:25, Tomas Heran<address@hidden> wrote:
>
>>
>> Hello.
>>
>> I've recently started evaluating libmicrohttpd for purposes of my
>> project and while I like very much what I've seen so far there are
>> specific requirements imposed by my execution environment which
>> make integrating MHD HTTP server a little challenging.
>>
>> Namely:
>>
>> - The program handles its connections independently from MHD (listening,
>> accepting new client connections and spawning threads to handle the
>> client connections, etc.)
>>
>> - The connections are presented to the rest of the program as
>> "objects", i.e. structures containing file descriptors which
>> are not accessible from the client handling code (furthermore,
>> even if the low-level fds were accessible, they aren't always
>> sockets)
>>
>> If I eventually decided to use MHD for my project, I'd have to
>> introduce to MHD a special kind of connection that is represented by a
>> set of functions for reading, writing, selecting/polling, closing etc.
>> and an "ID" to be able to find the particular "stream" that the
>> functions need to operate on.
>>
>> While understanding this may be very specific to my project and not too
>> interesting for many others, I'd still like to know whether you'd be
>> interested in accepting a patch that implements such kind of
>> connections? My intention would be to work with the community to
>> introduce a suitably generic/abstract representation that would
>> maximize re-use for other similar use cases.
>>
>> Please let me know.
>>
>> Thank you,
>> Tomas Heran
>
>

Hello,

it's been a while and I am sorry for the delay.

Please see the attached patch (against 0.9.37) that illustrates what
I'm trying to achieve. It basically boils down to allowing the consumer
to provide their own recv and send (read_handler and write_handler)
functions and an opaque void pointer that represents a connection
instead of providing a file descriptor ("pointing" to a socket).

The code as is is really useful when there's only one such connection
being handled by the MHD daemon (there's no polling implemented yet,
but definitely doable).

I also understand the patch attached isn't documented (the functions
aren't) properly according to the standards of the existing code, so
please don't take it as something that I'm asking to be included - it's
rather a concrete example showing what I'd like to achieve and what I
got to work for my prototype so far and to discuss further.

Please let me know what you think.

Thanks,
Tomas

PS: Having gone through the patch again right now, I see that I've also
made a change that's related to calling a completion handler (in the
situation when client hangs up). The comment explains the issue, I
hope. Please let me know whether I should file a separate "bug" for
that into bug-tracking. FWIW, all the tests ('make check') pass just
fine with this change, but I haven't gone through the testsuite to see
whether there's a test that would catch a bug if there was one
introduced by such a change. I will if asked to.

patch_non-fd_conns.txt
Description: Text document