Hey Burt,

LOL it sounds like they really are being odd about things and not trusting
your judgement like they ought to.. :P

Anyways, your questions regarding the multi interface...

You can actually use the fd stuff w/ the multi interface as well (have you
seen this page? http://curl.haxx.se/libcurl/c/libcurl-multi.html)

But, I personally use curl_multi_info_read
http://curl.haxx.se/libcurl/c/curl_multi_info_read.html to get information
about which requests are done. I'm not 100% sure if you are garaunteed to
get a message per handle though which sucks for you (we are a long way off
from having to use this code in a production setting so it's low priority
for me since it seems to work for all our current needs)

also, another option might be to make one multi handle per request. That's
kinda lame of course, but that way you can at least get all the niceness of
the multi interface (asynch requests) but still can know right away which
requests are done.

I'm kind of curious too about the "best practices" for detecting which easy
handle has been completed, when multiple are added to a multi handle.
On Fri, Jan 27, 2012 at 8:38 AM, <burt_at_burtbicksler.com> wrote:

> Hi,
>
> We have an application that monitors several hardware devices connected by
> USB. This application's primary task is to service the devices.
>
> We have to interface with a Web Server that is running on the local
> machine, and the Web application developers are somewhat clueless about
> interacting with hardware devices. Since they were already interacting
> with another hardware device via USB serial we originally proposed a simple
> TCP/IP connection to allow them to send notifications and requests and for
> returning data, and we have a working example.
>
> But they seem to be resistant to this approach even though it is the
> cleanest, and is similar to what they are already doing.
>
> So we are changing to use HTTP sending POST requests to them and receiving
> responses back by HTTP.
>
> Since the Web Application has a different priority, servicing the users
> for example, they tend to take their own sweet time responding to requests
> (in terms of hardware processing times). So we need to issue the request
> and continue doing processing of other hardware before we get the response
> from the Web Application. In our world most of the processing will be done
> in under a couple of hundred milliseconds, while the Web Application is
> taking a number of seconds to respond.
>
> So we are splitting the request and response processing, and ultimately
> using select to process the read fd(s) for the HTTP connection(s). Our
> current simple HTTP client works well but I would prefer to use libCurl to
> get the HTTPS support (another annoyance is that they insist on HTTPS even
> though everything is running on the same computer inside a locked box ;)).
>
> So my question. Is there a simple way to split the sending of the HTTP
> requests and the processing of the responses on a per connection basis
> using libCurl?
>
> I've looked at the one multi-socket example that I found but it seems a
> bit more complex than what I was looking for, and it sounds like when the
> curl_multi_socket_action() function is called that it will process any
> connections that are pending in the multi handle, and we need to track each
> individual connection that is processed for context.
>
> Is there another multi example available that would be closer to what we
> need to do? I've done some searching with Google but haven't turned up
> very much yet.
>
> I suspect that I could use the easy read callback to do the context
> processing for each response received, so I might revisit it looking at
> that approach.
>
> Thanks,
> Burt
>
>
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-01-27