Re: [libmicrohttpd] Protocol upgrade

[Evgeny Grin]

Dear Markus,

It's clear how to use this logic for HTTP connections.
But application may use any arbitrary protocol for "upgraded" sockets so
MHD doesn't know what should be interpreted as "request"(if word
"request" is applicable for protocol). The best what MHD could do with
"upgraded" sockets - is to forward data to application and back to remote.
That's implemented currently. For TLS connections, MHD hides all
TLS-related machinery and provides plain socket for application.

Not sure that I get idea about "pipe() on TLS". Could you explain it a
little?

-- 
Best Wishes,
Evgeny Grin

On 14.11.2016 14:58, Markus Doppelbauer wrote:
> Dear Evgeny,
> 
> Thanks a lot for your answer.
> I will have to live with this API - but I don't like it. A great API
> would be
> something similar to "MHD_create_response_from_callback()" and
> "suspend/resume_connection()".
> 
> But I understand that this is very difficult to implement.
> 
> Maybe I am wrong, but this would also obsolete the "pipe()" on TLS
> connections.
> 
> Thanks a lot
> Markus
> 
> 
> 
> Am Montag, den 14.11.2016, 14:05 +0300 schrieb Evgeny Grin:
>> Hi Markus,
>>
>> We are trying to avoid blocking of MHD by external processing of
>> "upgraded" socket data.
>> Currently these is no way to register such notification and it couldn't
>> be easily added for non-TLS connections.
>> But even if we'll add it - it will block MHD if you will process data in
>> the caller thread. And anyway you will need a poll()/select() to send data.
>> For simplicity - you can use poll() (which is available almost
>> everywhere) and separate thread for each upgraded socket. If you need
>> compatibility with older W32 versions - you can use select() for W32 as
>> select() on W32 doesn't have limitation on socket's number.
>>